The Apple logo is a registered trademark of Apple Computer, Inc. Use of the “keyboard”
Apple logo (Option-Shift-K) for commercial purposes without the prior written consent of
Apple may constitute trademark infringement and unfair compe-tition in violation of federal and state laws.
Apple Computer, Inc.
20525 Mariani Avenue
Cupertino, CA 95014-6299
408-996-1010
Apple, the Apple logo, APDA, AppleLink, AppleShare,
AppleTalk, Apple IIGS, A/UX, EtherTalk, HyperCard, Hyper-Talk, ImageWriter, LaserWriter, LocalTalk, Mac, Macintosh, MPW, MultiFinder, SANE, and TokenTalk are registered trade-marks of Apple Computer, Inc.
Apple Desktop Bus, Balloon Help, Finder, KanjiTalk, Moof, QuickDraw, ResEdit, TrueType, and Zhong-Wen Talk are trade-marks of Apple Computer, Inc.
Helvetica and Times are
registered trademarks of
Linotype Company.
ITC Zapf Dingbats is a registered trademark of International Typeface Corporation.
MacPaint is a registered trade-mark of Claris Corporation.
NuBus is a trademark of Texas
Instruments.
PostScript is a registered trade-mark, and Illustrator is a
trademark, of Adobe Systems
Incorporated.
Sony is a registered trademark of Sony Corporation.
UNIX is a registered trademark of UNIX System Laboratories, Inc.
Simultaneously published in the United States and Canada.
Limited Warranty on Media and Replacement
Even though Apple has
reviewed this manual, APPLE MAKES NO WARRANTY OR REPRESENTATION, EITHER EXPRESS OR IMPLIED, WITH RESPECT TO THIS MANUAL, ITS QUALITY, ACCURACY, MERCHANT-ABILITY, OR FITNESS FOR A PARTICULAR PURPOSE. AS A RESULT, THIS
MANUAL IS SOLD “AS
IS,” AND YOU, THE PUR-CHASER, ARE ASSUMING THE ENTIRE RISK AS TO ITS QUALITY AND
ACCURACY.
IN NO EVENT WILL APPLE BE LIABLE FOR DIRECT,
INDIRECT, SPECIAL,
INCIDENTAL, OR CONSE-QUENTIAL DAMAGES
RESULTING FROM ANY
DEFECT OR INACCURACY IN THIS MANUAL, even if advised of the possibility of such damages.
THE WARRANTY AND REMEDIES SET FORTH ABOVE ARE EXCLUSIVE AND IN LIEU OF ALL
OTHERS, ORAL OR
WRITTEN, EXPRESS OR
IMPLIED. No Apple dealer, agent, or employee is
authorized to make any
modification, extension, or
addition to this warranty.
Some states do not allow the exclusion or limitation of
implied warranties or liability for incidental or consequential damages, so the above
limitation or exclusion may not apply to you. This warranty gives you specific legal rights, and you may also have other rights which vary from state to state.
The Device Manager
Introduction to Devices and Drivers1-3
About the Device Manager1-4
Using the Device Manager1-7
Opening and Closing Device Drivers1-8
Communicating With Device Drivers1-10
Controlling and Monitoring Device Drivers1-13
Reference to the Device Manager1-15
Data Structures1-15
Routines1-18
Opening and Closing Device Drivers1-18
Reading From and Writing To Devices1-25
Controlling and Monitoring Devices1-31
Summary of the Device Manager1-39
1The Device Manager
This chapter describes how your application can use the Device Manager to transfer information into and out of the Macintosh. The Device Manager controls the exchange of information between applications and hardware devices. Often applications communicate with the Device Manager indirectly, by calling routines of other managers (for example, the File Manager) which use the Device Manager. However, sometimes applications must call Device Manager routines directly.
Read the information in this chapter if your application needs to use the Device Manager to communicate with a device. For example, you might need to use the Device Manager to communicate with a modem device on an expansion card. You would probably not need to use the Device Manager to communicate with a graphics device on an expansion card, as you would use QuickDraw instead. You also do not need to use the Device Manager directly to communicate with disk drives or printers, as you can use the File Manager or the Printing Manager.
To use this chapter, you should be familiar with resources and how the system searches resource files. See the chapter “The Resource Manager” in the Inside Macintosh: Macintosh Toolbox volume.
This chapter includes
n a brief introduction to devices and device drivers (the programs that control devices)
n a description of the Device Manager and how it manages device drivers
n a discussion of how to use Device Manager routines to exchange information with devices and device drivers
You can find specific information about the standard Macintosh device drivers, like the Disk Driver and the Serial Drivers, in separate chapters of this book. If you want to create your own device driver or desk accessory, you should first read this chapter and then read the chapter “Writing Your Own Device Driver” in this book.
Introduction to Devices and Drivers
A device is a physical part of the Macintosh, or a piece of external equipment, that can exchange information with applications or with the Operating System. Input devices transfer information into the Macintosh, while output devices receive information from the Macintosh. An I/O device can transfer information in either direction.
Devices transfer information in one of two ways. Character devices read or write a stream of characters, or bytes, one at a time; they can neither skip bytes nor go back to previous bytes. The serial ports and printers are character devices.
Block devices read and write entire blocks of bytes at one time; they can read or write any accessible block on demand. These devices are usually used to store and retrieve information. Disk drives are block devices.
Devices communicate with applications and with the Operating System through special programs called device drivers. These drivers act as translators, converting software requests into hardware actions and hardware actions into software results. A synchronous device driver completes each communication request before returning control to the system. An asynchronous device driver can initiate a data transfer and return control to the system before the entire transfer is complete. This type of device driver usually relies on interrupts from its hardware device to regain control of the processor and continue or complete the data transfer.
A device driver does not have to be associated with a device. In general, a device driver is a program that conforms to a predefined format and programming interface. Many device drivers take advantage of this predefined interface to perform tasks unrelated to actual physical devices. Desk accessories are an example of this kind of device driver.
Some device drivers are stored in the Macintosh ROM; others are stored in driver ('DRVR') resources, which are typically located in applications, system extension files, and the firmware of expansion cards. A driver resource contains information about the driver, including the driver name, and the code necessary for the driver to perform its functions. The Device Manager must load a driver from its driver resource into memory before your application or any part of the system can communicate with it.
The Device Manager opens certain device drivers at system startup time. These drivers make up the standard device drivers, which include the Disk Driver, the Serial Drivers, and printer drivers. The Device Manager opens other drivers when requested—typically by initialization ('INIT') resources, applications, and other drivers.
About the Device Manager
The Device Manager provides three basic services:
n It provides a common programming interface for applications and other managers to use when communicating with device drivers.
n It maintains data structures to manage open device drivers.
n It provides support routines useful when writing your own device drivers.
Typically, your application won’t communicate directly with device drivers; instead, it will call Device Manager routines or call the routines of another manager that calls the Device Manager. For example, your application can communicate with a disk driver by calling the Device Manager directly or by calling the File Manager, which calls the Device Manager.
Figure 1-1 shows the relationship between applications, the Device Manager, other managers, device drivers, and devices.
Communication with Devices
Before the Device Manager allows an application or another manager to communicate with a device driver, the driver must be open, which means the Device Manager has received a request to open the driver, has loaded the driver into memory if necessary, and has successfully called the driver’s opening routine.
When opening a device driver, the Device Manager creates a device control entry (DCE), which contains information about the device driver. For example, the device control entry contains a handle to the device driver code (or a pointer for device drivers in ROM). Typically, the Device Manager maintains one device control entry for each open device driver, but it is possible for multiple entries to refer to the same driver.
The Device Manager maintains another data structure, the unit table, to organize the device control entries. The unit table contains a handle to the device control entry for each open driver. The location of a driver’s device control entry in the unit table is called the driver’s unit number.
When you open a device driver, the Device Manager returns a driver reference number for the driver. You use the driver reference number, instead of the driver name, to identify the driver in subsequent communication requests. The driver reference number is related to the unit number by the following formula:
The Device Manager also maintains a driver request queue for each open device driver. At the head of this queue is the I/O request currently being processed by the device driver. The rest of the queue contains pending I/O requests—requests the Device Manager has received but not yet sent to the device driver. This queue allows your application to request a data transfer with a busy device and accomplish other tasks while the device satisfies previous requests.
With respect to the driver request queue, the Device Manager allows you make to three types of requests: synchronous, asynchronous, and immediate.
The terms synchronous and asynchronous have different meanings depending on their context.
When referring to a device driver, the term synchronous indicates that the driver completes the entire request before returning control to the Device Manager. The term asynchronous indicates that the driver can begin processing a request and return control to the Device Manager before the request is complete. When a driver is handling a request asynchronously, it usually relies on interrupts from the hardware device to continue processing the request.
When referring to requests, the terms synchronous and asynchronous indicate how the Device Manager processes the request. Actually, you can specify that the Device Manager process the request in one of three ways.
n Synchronous requests. When you make a synchronous request, the Device Manager places your request at the end of the driver request queue. The Device Manager then waits until the driver has handled every request in the queue, including the synchronous one, before returning control to your application. Notice there can never be more than one synchronous request per driver request queue at any given time. (The driver can handle each request in the queue synchronously or asynchronously, but the Device Manager does not return control to your application until the final request is complete.)
n Asynchronous requests. When you make an asynchronous request, the Device Manager places your request at the end of the driver request queue, but it returns control to your application immediately—potentially before the request is satisfied. Your application is free to perform other tasks while the driver satisfies the requests in its queue. The Device Manager provides mechanisms for your application to determine when the driver has satisfied the request.
n Immediate requests. When you call a Device Manager routine immediately, the Device Manager sends your request directly to the driver, bypassing the driver request queue, and returns control to your application when the request is complete. An asynchronous device driver, which can process a single communication request in a number of steps, might be in the middle of processing another request. A similar situation can exist even for a synchronous device driver if you make the immediate request during interrupt time. Device drivers that can handle this situation correctly are called reentrant drivers. As some device drivers are not reentrant, you should always check a driver’s documentation before making immediate requests.
The next section, “Using the Device Manager,” describes how to specify the manner in which the Device Manager should process your request.
The chapter “Writing Your Own Device Driver” in this book gives more information about the Device Manager data structures and also describes the Device Manager routines useful for writing device drivers.
Using the Device Manager
Your application can use Device Manager routines to communicate with devices. It can use these routines to open and close device drivers, to exchange information with them, and to otherwise control and monitor them.
The Device Manager includes high-level and low-level versions of most of its routines. The high-level versions are somewhat easier to use, but they allow less control of how the Device Manager executes the routine (for example, they always execute synchronously) and they return less information to your application. Conversely, the low-level routines require some additional setup, but they allow you greater control and return more information.
The high-level routines differ in form, but the low-level routines all have the form:
FUNCTION PBRoutineName (paramBlock: ParmBlkPtr;
async: Boolean): OSErr;
The first parameter paramBlock is a Device Manager parameter block. You can use fields of this data structure to pass more complete information to the driver than you can with high-level routines, and the driver uses the same data structure to pass information back. The section “Data Structures,” on page 1-14, discusses the fields of the parameter block in detail.
The second parameter async specifies whether the Device Manager should execute the routine asynchronously. If you set this parameter to FALSE, the Device Manager adds the parameter block to the driver request queue and waits until the driver completes the request (which means it has completed all previously queued requests) before returning control to your application.
If you set the async parameter to TRUE, the Device Manager adds the parameter block to the driver request queue and returns control to your application immediately. In this case, a noErr result code signifies that the request was successfully queued, not that the request was successfully completed. Your application can determine when the driver has completed the request by periodically polling the ioResult field of the parameter block. The Device Manager sets this field to 1 when the request is queued, and the driver stores the actual result code there when it completes the request.
You can also provide a pointer to a completion routine in the ioCompletion field of the parameter block. The Device Manager executes this routine when the driver completes the asynchronous request.
ASSEMBLY-LANGUAGE NOTE
You can call a Device Manager routine asynchronously, bypassing the request queue, by setting the immediate bit (bit 9) of the trap word. However, remember that the driver might have an asynchronous request pending. In fact, if you make an immediate request during interrupt time, the driver might be currently executing another request. Be sure the driver is reentrant—that is, that it can handle these situations.<36pt\>\x12 <8bat\>u
Opening and Closing Device Drivers
You must open a driver before your application can communicate with it. The Device Manager provides three functions for opening device drivers: OpenDriver, PBOpen, and OpenSlot. Each of these functions requires a driver name and returns a driver reference number.
A driver name consists of a period (.) followed by any sequence of 1 to 254 printing characters; for example, .ATP is the name of one of the high-level AppleTalk drivers.
The initial period in a driver name allows the Device Manager and the File Manager, which both use the PBOpen function, to distinguish between device driver names and file names. For the same reason, filenames should not start with a period.<36pt\>\x12 <8bat\>u
The Device Manager assigns each open device driver a driver reference number. This number allows the Device Manager to locate the driver’s device control entry in the unit table.
The OpenDriver function, which is the high-level opening routine, takes the driver name as its first parameter and returns the driver reference number in its second parameter.
Listing 1-1 shows how to use the OpenDriver function to open a driver from a resource file.
Opening a device driver from a resource file
VAR gDrvrRefNum : Integer;
PROCEDURE MyOpenDriver;
VAR
drvrHdl : Handle;
drvrID : Integer;
tempDrvrID : Integer;
drvrType : ResType;
drvrName : Str255;
err : OSErr;
BEGIN
tempDrvrID := FindEmptySpaceInUnitTable;
drvrHdl := GetNamedResource('DRVR','.DRIVER');
GetResInfo(drvrHdl, drvrID, drvrType, drvrName);
SetResInfo(drvrHdl, tempDrvrID, drvrName);
err := OpenDriver('.DRIVER',gDrvrRefNum);
IF (err = NoErr) THEN
DetachResource(drvrHdl);
drvrHdl := GetNamedResource('DRVR',drvrName);
SetResInfo(drvrHdl,drvrID, drvrName);
END;
The OpenDriver function uses the resource ID of the driver resource to determine where in the unit table to store the device control entry for the driver. Unfortunately, the OpenDriver function does not check to see if another device control entry is already located in that position in the unit table.
Therefore, the MyOpenDriver procedure begins by finding an empty space in the unit table and then changes the resource ID of the driver resource before calling the OpenDriver function. (The chapter “Writing Your Own Device Driver” gives a complete definition of the FindEmptySpaceInUnitTable function.)
After the driver is open, the MyOpenDriver procedure detaches the resource and restores the original resource ID.
The PBOpen and OpenSlot functions, which are low-level functions, use the Device Manager parameter block, which is described fully in “Data Structures” on page 1-14. Both of these functions expect a pointer to the driver name in the ioNamePtr field of the parameter block and return the reference number in the ioRefNum field.
You use the PBOpen and OpenSlot functions in preference to the OpenDriver function when you want more control over how the Device Manager opens the device driver. For example, you can set read and write permissions for the device with the ioPermssn field of the parameter block.
You use the OpenSlot function to open drivers that serve slot devices. This function uses an extended parameter block that includes extra fields specific to slot device drivers. You use the PBOpen function to open any other device drivers.
You must open device drivers synchronously. If a device driver is already open, the driver-opening routines simply return the driver reference number.
The remaining Device Manager routines require your application to use the reference number, instead of the driver name, when referring to a device.
When you are done using a driver, you may want to close it. However, you should generally not close drivers that might be needed by the system or by other applications. Whether you should close a particular driver depends on the driver. You should check the documentation for the driver if you are not sure. Other chapters in Inside Macintosh give this information for the standard Macintosh drivers.
If you do want to close a driver, you can use the high-level CloseDriver function or the low-level PBClose function. Listing 1-2 shows how to use the PBCLose function to close the driver opened in Listing 1-1.
Closing a device driver
PROCEDURE MyCloseDriver;
VAR
paramBlock : ParamBlockRec;
err : OSErr;
BEGIN
paramBlock.ioCompletion := nil;
paramBlock.ioRefNum := gDrvrRefNum;
err := PBClose (@paramBlock, FALSE);
END;
The MyCloseDriver procedure specifies the driver to close by providing the driver reference number in the ioRefNum field of the parameter block and indicates that the Device Manager should not execute a completion routine by specifying NIL in the ioCompletion field of the parameter block.
Communicating With Device Drivers
Once a driver is open and you have its reference number, you can use Device Manager communication routines to exchange information with it.
When you want to send information to a device driver, you first store the information in a data buffer and then call the FSWrite function or the PBWrite function. When you want to receive information from a device driver, you first allocate a data buffer to hold the information, and then call the FSRead or PBRead function. You must specify the number of bytes you want transferred when calling any of these functions.
Like all low-level routines, the PBWrite and PBRead functions allow you to transfer the information asynchronously, and with these functions you can provide a completion routine. These functions also allow you to specify a drive number, a positioning mode, and a positioning offset in the ioVRefNum, ioPosMode, and ioPosOffset fields of the parameter block. The Device Manager uses the positioning mode and positioning offset to determine where on a block device the transfer will occur. The Device Manager simply passes the drive number onto the driver. Be sure you specify these values in a manner compatible with the particular driver.
The Device Manager defines three positioning modes for block devices:
n At the current position. With this mode, the transfer begins at the current position on the medium—typically where the last transfer ended.
n Offset from the start. This mode allows you to provide a positioning offset, which specifies at how many bytes from the beginning of the medium the transfer will begin.
n Offset from the mark. With this mode you can provide a positioning offset that specifies at how many bytes from the current position the transfer will begin.
On completion, the PBRead and PBWrite functions return the total number of bytes actually transferred in the ioActCount field of the parameter block. For block devices, these functions also return a new positioning offset in the ioPosOffset field.
Certain device drivers provide additional abilities with the reading and writing functions. For example, the Disk Driver allows you to use the PBRead function to verify that data written to a block device matches the data in memory. To do this, you add the read-verify constant
CONST rdVerify = 64;
to the ioPosMode field of the parameter block, as explained in the description of the PBRead function in “Routines,” on page 1-25.
Listing 1-3 shows an example that exchanges information with a device driver.
Communicating with a device driver
PROCEDURE MyReadFromDriver;
VAR
paramBlock : ParamBlockRec;
err : OSErr;
readBuf : Str255;
BEGIN
paramBlock.ioCompletion := nil;
paramBlock.ioRefNum := gDrvrRefNum;
paramBlock.ioBuffer := @readBuf;
paramBlock.ioReqCount := 256;
err := PBRead (@paramBlock, FALSE);
END;
PROCEDURE MyWriteToDriver;
VAR
paramBlock : ParamBlockRec;
err : OSErr;
buffer : Str255;
BEGIN
buffer := 'Data to Write';
paramBlock.ioCompletion := nil;
paramBlock.ioRefNum := gDrvrRefNum;
paramBlock.ioBuffer := @buffer;
paramBlock.ioReqCount := 14;
err := PBWrite (@paramBlock, FALSE);
END;
The MyReadFromDriver procedure uses a parameter block to specify the device driver (by reference number), the number of bytes to read, a pointer to a buffer to receive the data, and NIL for the completion routine. It then sends the parameter block to the PBRead function. The Device Manager appends the parameter block to the end of the driver’s request queue. Since the parameter async is set to FALSE, the Device Manager does not return control to the MyReadFromDriver procedure until the driver has completed every request in its queue.
The MyWriteToDriver procedure uses a parameter block to specify the device driver (by reference number), the size of the data to write, a pointer to the actual data, and NIL for the completion routine. It then sends the parameter block to the PBWrite function. The Device Manager appends the parameter block to the end of the driver’s request queue. Since the parameter async is set to FALSE, the Device Manager does not return control to the MyWriteToDriver procedure until the driver has completed every request in its queue.
Controlling and Monitoring Device Drivers
In addition to the reading and writing routines, the Device Manager provides routines that allow your application to control and monitor device drivers in other ways.
The Control and PBControl functions allow your application to send control information to a driver. The actual type of control information to which drivers respond varies greatly from driver to driver. For example, you can send control information to the standard Disk Driver requesting that it eject the disk.
The Status and PBStatus functions allow your application to obtain status information from a driver. Again, the type of information drivers provide varies widely from driver to driver. As an example of status information, the Serial Driver provides a breakdown of the types of errors that have occurred recently.
Like all low-level routines, you can call the PBControl and PBStatus functions asynchronously, and with these functions you can provide a completion routine.
Because of the diversity of device drivers, the controlling and monitoring functions have two general parameters: csCode and csParamPtr. The csCode parameter allows you to specify a driver-dependent code that indicates the type of control or status information. The csParamPtr parameter allows you to send or receive the actual control or status information.
Notice that although the controlling and monitoring functions have a different interface than the reading and writing functions, their outcome is much the same: they exchange information with device drivers. Some device drivers (AppleTalk, for instance) implement all communication, even reading and writing, through the controlling and monitoring functions.
The sample device driver described in the chapter “Writing Your Own Device Driver” accepts control and status requests. Listing 1-4 shows how to provide control information and determine status information for that device driver.
Controlling and monitoring a device driver
PROCEDURE MyIssueDriverControl;
VAR
paramBlock : ParamBlockRec;
err : OSErr;
BEGIN
paramBlock.ioCompletion := nil;
paramBlock.ioCRefNum := gDrvrRefNum;
paramBlock.csCode := 100;
paramBlock.csParam[0] := 3; { beep 3 times }
err := PBControl (@paramBlock, FALSE);
END;
PROCEDURE MyGetDriverStatus;
VAR
paramBlock : ParamBlockRec;
err : OSErr;
beepTimes : Integer;
BEGIN
paramBlock.ioCompletion := nil;
paramBlock.ioCRefNum := gDrvrRefNum;
paramBlock.csCode := 100;
err := PBStatus (@paramBlock, FALSE);
IF (err = noErr) THEN
beepTimes := paramBlock.csParam[0];
END;
The MyIssueDriverControl procedure begins by setting up the fields of a parameter block. The ioCRefNum field specifies the device driver reference number and the ioCompletion field specifies NIL for the completion routine. The csCode field specifies the type of control information being sent. The sample device driver from the chapter “Writing Your Own Device Driver” interprets a value of 100 as a request for the device driver to produce a system beep. When the value of the csCode field is 100, the value of the csParam field signifies the number of times to beep.
The MyGetDriverStatus procedure also begins by setting up the fields of a parameter block. The ioCRefNum field specifies the device driver reference number and the ioCompletion field specifies NIL for the completion routine. The csCode field specifies the type of status information being requested. For this particular device driver, the value 128 indicates the driver should return the number of times it last beeped. The PBStatus function causes the driver to store this information in the csParam field of the parameter block.
Reference to the Device Manager
This section describes the data structures and routines that allow you to use the Device Manager to communicate with device drivers.
The “Data Structures” section shows the Pascal definition for the Device Manager parameter block. The “Routines” section describes the routines you use to open and close device drivers, read from and write to device drivers, and control and monitor device drivers. Constants used by these routines are listed in the section “Summary of the Device Manager,” on page 1-37.
The chapter “Writing Your Own Device Driver” in this book describes the Device Manager data structures and routines useful when writing a device driver.
Data Structures
The Device Manager provides both a high-level and a low-level interface for communicating with device drivers. You pass information to the low-level routines in a Device Manager parameter block.
The Device Manager uses two forms of the parameter block: one for the opening, closing, reading, and writing routines and another for controlling and monitoring routines. Other managers use different variants of this data structure.
ioVRefNum : Integer; {volume reference or drive number}
CASE ParamBlkType OF
ioParam:
(ioRefNum: Integer; {driver reference number }
ioVersNum: SignedByte; {not used }
ioPermssn: SignedByte; {read/write permission }
ioMisc: Ptr; {not used}
ioBuffer: Ptr; {pointer to data buffer}
ioReqCount: LongInt; {requested number of bytes }
ioActCount: LongInt; {actual number of bytes }
ioPosMode: Integer; {positioning mode }
ioPosOffset: LongInt); {positioning offset }
cntrlParam:
(ioCRefNum: Integer; {driver reference number }
csCode: SignedByte; {type of request }
csParam: ARRAY[1..10] OF Integer);
{control or status info }
END;
END;
qLink Used internally by the Device Manager.
qType Used internally by the Device Manager.
ioTrap Used internally by the Device Manager.
ioCmdAddr Used internally by the Device Manager.
ioCompletion Specifies a pointer to a completion routine. When making asynchronous requests, you must set this field to NIL if you are not specifying a completion routine. The Device Manager automatically sets this field to NIL when you make a synchronous request.
ioResult Contains a value indicating whether the routine completed successfully. The Device Manager sets this field to 1 when it queues an asynchronous request. When the driver completes the request, it places the actual result code in this field. You can poll this field to detect when the driver has completed the request and to determine its result code. The Device Manager executes the completion routine after this field receives the result code.
ioNamePtr Points to the name of the driver. You use this field only when opening a driver.
ioVRefNum Contains the drive number, if any. The meaning of this field depends on the device driver. The Disk Driver uses this field to identify disk devices.
I/O field descriptions
ioRefNum Specifies the driver reference number.
ioVersNum Not used.
ioPermssn Contains the read/write permission of the driver. When you open a driver, you must supply one of the following values in this field:
CONST fsCurPerm = 0; {retain current permission}
fsRdPerm = 1; {allow reads only}
fsWrPerm = 2; {allow writes only}
fsRdWrPerm = 3; {allow reads and writes}
The Device Manager compares subsequent read and write requests with the read/write permission of the driver. If the request type is not permitted, the Device Manager returns a a result code indicating the error.
ioMisc Not used.
ioBuffer Points to the data buffer for the driver to use for reads or writes.
ioReqCount Specifies the requested number of bytes for the driver to read or write.
ioActCount Indicates the actual number of bytes the driver reads or writes.
ioPosMode Specifies the positioning mode used by drivers of block devices. Bits 0 and 1 of this field indicate where an operation should begin relative to the physical beginning of the block-formatted medium. You can use the following constants to test or set the value of these bits:
CONST fsAtMark = 0; {at current position}
fsFromStart = 1; {offset from beginning}
fsFromMark = 2; {offset from current pos.}
The Disk Driver allows you to add the following constant to this field to specify a read-verify operation:
CONST rdVerify = 64; {read-verify mode}
See the description of the PBRead function in “Reading From and Writing To Devices,” on page 1-25.
ioPosOffset Specifies the byte offset, relative to the position specified by the positioning mode, where the driver should perform the operation. If you specify the fsAtMark positioning mode, the Device Manager ignores this field.
Control and status field descriptions
ioCRefNum Contains the driver reference number.
csCode Contains a value identifying the type of the control or status request. Each driver may interpret this number differently.
csParam Contains the actual control or status information for the request; this field is declared generically as an array of ten integers because its actual format varies from one type of control or status request to the next.
Routines
This section describes the Device Manager routines you use to open and close device drivers, read from and write to device drivers, and control and monitor device drivers.
The low-level routines in this section accept a pointer to a parameter block as a parameter. For these routines, the routine description includes a list of the fields in the parameter block that are used by the routine.
Opening and Closing Device Drivers
A driver must be open before your application can communicate with it. You can use the OpenDriver or PBOpen function to open closed drivers or to determine the driver reference number of an already open device driver. You can use the OpenSlot function to open drivers that serve slot devices.
When you have finished communicating with a driver, you can close it if you are sure no other application or part of the system needs to use it. You can use the CloseDriver or PBClose function to close a driver.
The PBOpen and PBClose functions use the I/O fields of the parameter block. The OpenSlot function uses the I/O fields and some additional fields that apply only to slot devices.
1OpenDriver
You can use the OpenDriver function to open a closed device driver or to determine the reference number of an open device driver.
FUNCTION OpenDriver (name: Str255;
VAR refNum: Integer): OSErr;
name Specifies the name of the driver to open. A driver name consists of a period (.) followed by any sequence of 1 to 254 printing characters. The Device Manager ignores case (but not diacritical marks) when comparing names.
refNum Contains the reference number of the driver. The OpenDriver function uses this parameter to return the reference number of the open driver.
DESCRIPTION
The OpenDriver function opens the device driver specified by the name parameter and returns its reference number in the refNum parameter. The Device Manager searches the drivers that are already installed in the unit table before searching driver resources to avoid replacing a current driver. If the specified driver is already open, this function simply returns the driver’s reference number.
If the specified driver is not already open, the Device Manager searches for a driver resource with the specified name. If the Device Manager finds such a resource, the resource ID determines the location in the unit table where the Device Manager installs the driver’s DCE. Since another driver might already be installed in the unit table at the location determined by the resource ID, you should first search for an unused location in the unit table and renumber the resource accordingly before calling this function. See Listing 1-1 on page 1-8 for an example.
The OpenDriver function is a high-level version of the low-level PBOpen function. Use the PBOpen function when you need to specify read/write permission for the driver. See the description of the PBOpen function on page 1-18.
SPECIAL CONSIDERATIONS
The OpenDriver function may move memory; you should not call it at interrupt time.
RESULT CODES
noErr 0 No error
badUnitErr –21 Reference number out of range or not in use
unitEmptyErr –22 DCE points to null driver
openErr –23 Driver can’t perform requested open
dInstErr –26 Couldn’t find driver in resource file
SEE ALSO
For information about the low-level routines for opening devices, see the next section, which describes the PBOpen function, and the description of the OpenSlot function on page 1-20.
For an example of opening a device driver, see Listing 1-1 on page 1-8.
1PBOpen
You can use the PBOpen function to open a closed device driver or to determine the reference number of an open device driver.
FUNCTION PBOpen (paramBlock: ParmBlkPtr;
async: Boolean): OSErr;
paramBlock Contains a pointer to the parameter block.
async Specifies to the Device Manager whether the request is
asynchronous. You should always set this field to FALSE.
You specify values and receive return values in a Device Manager parameter block.
<symbol\>\xae ioCompletion ProcPtr A pointer to completion routine.
<symbol\>\xac ioResult OSErr The result code of the function.
<symbol\>\xae ioNamePtr StringPtr
A pointer to the driver name.
<symbol\>\xac ioRefNum Integer The driver reference number.
<symbol\>\xae ioPermssn SignedByte
Read/write permission.
DESCRIPTION
The PBOpen function opens the device driver specified by the ioNamePtr field, installing it if necessary, and returns its reference number in the ioRefNum field. The Device Manager searches the drivers that are already installed in the unit table before searching driver resources to avoid replacing a current driver. If the specified driver is already open, this function returns the driver reference number already belonging to the driver.
If the specified driver is not already open, the Device Manager searches for a driver resource with the specified name. If the Device Manager finds such a resource, the resource ID determines the location in the unit table where the Device Manager installs the driver’s DCE. Since another driver might already be installed in the unit table at the location determined by the resource ID, you should first search for an unused location in the unit table and renumber the resource accordingly before calling this function. See Listing 1-1 on page 1-8 for an example.
If the driver returns a negative result in register D0, the Device Manager returns the result code in the ioResult parameter and does not open the driver.
SPECIAL CONSIDERATIONS
The PBOpen function may move memory; you should not call it at interrupt time.
ASSEMBLY-LANGUAGE INFORMATION
The trap macro for the PBOpen function is _Open ($A000). You must setup register A0 with the address of the parameter block. When _Open returns, register D0 contains the result code. Register D0 is the only register affected by this routine.
Registers on entry
A0 address of the parameter block
Registers on exit
D0 result code
RESULT CODES
noErr 0 No error
badUnitErr –21 Reference number out of range or not in use
unitEmptyErr –22 DCE points to null driver
openErr –23 Driver can’t perform requested open
dInstErr –26 Couldn’t find driver in resource file
SEE ALSO
For information about the high-level routine for opening device drivers, see the previous section, which describes of the OpenDriver routine.
For information about the low-level routine for opening device drivers that serve devices on expansion cards, see the next section, which describes of the OpenSlot routine.
For an example of opening a device driver, see Listing 1-1 on page 1-8.
1OpenSlot
You can use the OpenSlot function to open a device driver that serves a slot device.
FUNCTION OpenSlot (paramBlock: ParmBlkPtr;
async: Boolean) : OSErr;
paramBlock Contains a pointer to the parameter block.
async Specifies to the Device Manager whether the request is
asynchronous. You should always set this field to FALSE.
You specify values and receive return values in a Device Manager parameter block with a few additional fields that apply only to slot devices.
<symbol\>\xae ioCompletion ProcPtr Pointer to completion routine.
<symbol\>\xae ioMix Ptr Reserved for use by driver Open routine.
<symbol\>\xae ioFlags Integer Determines number of additional fields.
<symbol\>\xae ioSlot SignedByte
Slot number.
<symbol\>\xae ioId SignedByte
Slot resource ID.
Additional fields—multiple devices
<symbol\>\xae ioMix Ptr Reserved for use by driver Open routine.
<symbol\>\xae ioFlags Integer Determines number of additional fields.
<symbol\>\xae ioSEBlkPtr Ptr Pointer to external parameter block.
DESCRIPTION
The OpenSlot function is equivalent to the PBOpen function, except that it sets the immediate bit (bit 9) of the trap word, which signals the _Open routine that the parameter block includes additional fields.
If the slot resource, which is defined in the chapter “The Slot Manager” in this book, serves a single device, you should clear all the bits of the ioFlags field and include the slot number and slot resource ID in the ioSlot and ioID fields.
If the slot resource serves multiple devices, you should set the fMulti bit of the ioFlags field (clearing all other bits to 0), and specify, in the ioSEBlkPtr field, an external parameter block that is customized for the devices installed in the slot.
See the chapter “The Slot Manager” in this book for more details.
SPECIAL CONSIDERATIONS
The OpenSlot function may move memory; you should not call it at interrupt time.
ASSEMBLY-LANGUAGE INFORMATION
The trap macro for the OpenSlot function is _Open ($A200). The immediate bit (bit 9) of the trap word is set to signal to that the parameter block contains the additional fields.
You must setup register A0 with the address of the parameter block. When _Open returns, register D0 contains the result code. Register D0 is the only register affected by this routine.
Registers on entry
A0 address of the parameter block
Registers on exit
D0 result code
RESULT CODES
noErr 0 No error
badUnitErr –21 Reference number out of range or not in use
unitEmptyErr –22 DCE points to null driver
openErr –23 Driver can’t perform requested open
dInstErr –26 Couldn’t find driver in resource file
SEE ALSO
For information about the low-level routine for opening other device drivers, see the previous section, which describes the PBOpen routine.
For an example of opening a device driver, see Listing 1-1 on page 1-8.
1CloseDriver
You can use the CloseDriver function to close an open device driver.
FUNCTION CloseDriver (refNum: Integer) : OSErr;
refNum Contains the reference number of the driver returned by the driver-opening function.
DESCRIPTION
The CloseDriver function closes the device driver indicated by the refNum parameter. The Device Manager completes any pending I/O for this driver and releases the memory used by the driver.
You should not close drivers that other applications may be using, such as the Disk Driver, the AppleTalk drivers, and so on.<36pt\>\x12 <8bat\>s
The CloseDriver function is a high-level version of the low-level PBClose function. Use the PBClose function when you want to specify a completion routine. See the description of the PBClose function on page 1-22.
SPECIAL CONSIDERATIONS
The CloseDriver function does not move memory; you may call it at interrupt time.
RESULT CODES
noErr 0 No Error
badUnitErr –21 Reference number out of range or not in use
unitEmptyErr –22 DCE points to null driver
notOpenErr –26 Driver isn’t open
abortErr –27 Close request aborted by KillIO
SEE ALSO
For information about the low-level routine for closing device drivers, see the next section, which describes the PBClose function.
1PBClose
You can use the PBClose function to close an open device driver.
FUNCTION PBClose (paramBlock: ParmBlkPtr;
async: Boolean): OSErr;
paramBlock Contains a pointer to the parameter block.
async Specifies to the Device Manager whether the request is asynchronous.
You specify values and receive return values in a Device Manager parameter block.
<symbol\>\xae ioCompletion ProcPtr Pointer to completion routine.
The PBClose function closes the device driver specified by the ioRefNum field. The Device Manager completes any pending I/O for this driver and releases the memory used by the driver.
You should not close drivers that other applications may be using, such as the Disk Driver, the AppleTalk drivers, and so on.<36pt\>\x12 <8bat\>s
If the driver returns a negative result in register D0, the Device Manager returns this result code in the ioResult parameter and does not close the driver.
SPECIAL CONSIDERATIONS
The PBClose function does not move memory; you may call it at interrupt time.
ASSEMBLY-LANGUAGE INFORMATION
The trap macro for the PBClose function is _Close ($A001). Set bit 10 of the trap word to execute this routine asynchronously. Set bit 9 to execute it immediately.
You must setup register A0 with the address of the parameter block. When _Close returns, register D0 contains the result code. Register D0 is the only register affected by this routine.
Registers on entry
A0 address of the parameter block
Registers on exit
D0 result code
RESULT CODES
noErr 0 No Error
badUnitErr –21 Reference number out of range or not in use
unitEmptyErr –22 DCE points to null driver
notOpenErr –26 Driver isn’t open
abortErr –27 Close request aborted by KillIO
SEE ALSO
For information about the high-level routine for closing device drivers, see the previous section, which describes the CloseDriver function.
Reading From and Writing To Devices
You can use either the FSRead or PBRead function to read information from a device driver and you can use the FSWrite or PBWrite function to write information to a device driver.
The PBRead and PBWrite functions use the additional I/O fields of the parameter block, as described on page 1-15.
1FSRead
You can use the FSRead function to read data from an open driver into a data buffer.
FUNCTION FSRead (refNum: Integer; VAR count: LongInt;
buffPtr: Ptr): OSErr;
refNum Specifies the reference number of the driver.
count Indicates the number of bytes to read.
buffPtr Points to a data buffer to hold the data.
DESCRIPTION
Before calling the FSRead function, your application should allocate a data buffer large enough to hold the data to be read. The FSRead function attempts to read the number of bytes indicated by the count parameter from the specified device driver, and transfer them to this data buffer. After the transfer is complete, the count parameter indicates the number of bytes actually read.
Be sure your buffer is large enough to hold the number of bytes specified by the count parameter, or this function may corrupt memory. <36pt\>\x12 <8bat\>s
The FSRead function is a high-level version of the low-level PBRead function. Use the PBRead function when you want to request asynchronous reading or need to specify a drive number or a positioning mode and offset. See the next section, which describes the PBRead function.
SPECIAL CONSIDERATIONS
The FSRead function does not move memory. However, you should be sure the device driver does not move memory in response to a read request before you call this function at interrupt time.
RESULT CODES
noErr 0 No Error
readErr –19 Driver can’t respond to read requests
badUnitErr –21 Reference number out of range or not in use
unitEmptyErr –22 DCE points to null driver
notOpenErr –26 Driver isn’t open
abortErr –27 Read aborted by KillIO
SEE ALSO
For information about the low-level routine for reading from device drivers, see the next section, which describes the PBRead function.
1PBRead
You can use the PBRead function to read data from an open driver into a data buffer.
FUNCTION PBRead (paramBlock: ParmBlkPtr; async: Boolean) : OSErr;
paramBlock Contains a pointer to the parameter block.
async Specifies to the Device Manager whether the request is asynchronous.
You specify values and receive return values in a Device Manager parameter block.
<symbol\>\xae ioCompletion ProcPtr Pointer to completion routine.
Before calling the PBRead function, your application should allocate a data buffer large enough to hold the data to be read. The PBRead function attempts to read the number of bytes indicated by the ioReqCount field from the specified device driver and transfer them to this data buffer. After the transfer is complete, the ioActCount field indicates the number of bytes actually read.
Be sure your buffer is large enough to hold the number of bytes specified by the count parameter, or this function may corrupt memory. <36pt\>\x12 <8bat\>s
For block devices such as disk drivers, the PBRead function allows you to specify a drive number in the ioVRefNum field and specify a positioning mode and offset in the ioPosMode and ioPosOffset fields. Bits 0 and 1 of the ioPosMode field indicate where an operation should begin relative to the physical beginning of the block-formatted medium. You can use the following constants to test or set the value of these bits:
CONST fsAtMark = 0; {at current position}
fsFromStart= 1; {offset from beginning}
fsFromMark = 2; {offset from current position}
After the transfer is complete, the ioPosOffset field indicates the current position of the block device.
The Disk Driver allows you to use the PBRead function to verify that data written to a block device matches the data in memory. To do this, call PBRead immediately after writing the data, and add the read-verify constant
CONST rdVerify = 64; {read-verify mode}
to the ioPosMode field of the parameter block.
SPECIAL CONSIDERATIONS
The PBRead function does not move memory. However, you should be sure the device driver does not move memory in response to a read request before you call this function at interrupt time.
ASSEMBLY-LANGUAGE INFORMATION
The trap macro for the PBRead function is _Read ($A002). Set bit 10 of the trap word to execute this routine asynchronously. Set bit 9 to execute it immediately.
You must setup register A0 with the address of the parameter block. When _Read returns, register D0 contains the result code. Register D0 is the only register affected by this routine.
Registers on entry
A0 address of the parameter block
Registers on exit
D0 result code
RESULT CODES
noErr 0 No error
readErr –19 Driver can’t respond to read requests
badUnitErr –21 Reference number out of range or not in use
unitEmptyErr –22 DCE points to null driver
notOpenErr –26 Driver isn’t open
abortErr –27 Read aborted by KillIO
ioErr –36 Data doesn’t match in read-verify mode
SEE ALSO
For information about the high-level routine for reading from device drivers, see the previous section, which describes the FSRead function.
1FSWrite
You can use the FSWrite function to write data from a data buffer to an open driver.
FUNCTION FSWrite (refNum: Integer; VAR count: LongInt;
buffPtr: Ptr) : OSErr;
refNum Specifies the reference number of the driver.
count Indicates the number of bytes to write.
buffPtr Points to the data buffer that holds the data.
DESCRIPTION
The FSWrite function attempts to write the number of bytes indicated by the count parameter from the data buffer pointed to by the buffPtr parameter to the specified device driver. After the transfer is complete, the count parameter indicates the number of bytes actually written.
The FSWrite function is a high-level version of the low-level PBWrite function. Use the PBWrite function when you want to request asynchronous writing or need to specify a drive number or a positioning mode and offset. See the next section, which describes the PBWrite function, for further information.
SPECIAL CONSIDERATIONS
The FSWrite function does not move memory. However, you should be sure the device driver does not move memory in response to a write request before you call this function at interrupt time.
RESULT CODES
noErr 0 No error
writErr –20 Driver can’t respond to write requests
badUnitErr –21 Reference number out of range or not in use
unitEmptyErr –22 DCE points to null driver
notOpenErr –26 Driver isn’t open
abortErr –27 Write aborted by KillIO
SEE ALSO
For information about the low-level routine for writing to device drivers, see the next section, which describes the PBWrite function.
1PBWrite
You can use the PBWrite function to write data from a data buffer to an open driver.
FUNCTION PBWrite (paramBlock: ParmBlkPtr;
async: Boolean): OSErr;
paramBlock Contains a pointer to the parameter block.
async Specifies to the Device Manager whether the request is asynchronous.
You specify values and receive return values in a Device Manager parameter block.
<symbol\>\xae ioCompletion ProcPtr Pointer to completion routine.
The PBWrite function attempts to write the number of bytes indicated by the ioReqCount field from the data buffer pointed to by the ioBuffer field to the driver specified by the ioRefNum field. After the transfer is complete, the ioActCount field indicates the number of bytes actually written.
For block devices such as disk drivers, the PBWrite function allows you to specify a drive number in the ioVRefNum field and specify a positioning mode and offset in the ioPosMode and ioPosOffset fields. Bits 0 and 1 of the ioPosOffset field indicate where an operation should begin relative to the physical beginning of the block-formatted medium. You can use the following constants to test or set the value of these bits:
CONST fsAtMark = 0; {at current position}
fsFromStart= 1; {offset from beginning}
fsFromMark = 2; {offset from current position}
After the transfer is complete, the ioPosOffset field indicates the new current position of a block device.
SPECIAL CONSIDERATIONS
The PBWrite function does not move memory. However, you should be sure the device driver does not move memory in response to a write request before you call this function at interrupt time.
ASSEMBLY-LANGUAGE INFORMATION
The trap macro for the PBWrite function is _Write ($A003). Set bit 10 of the trap word to execute this routine asynchronously. Set bit 9 to execute it immediately.
You must setup register A0 with the address of the parameter block. When _Write returns, register D0 contains the result code. Register D0 is the only register affected by this routine.
Registers on entry
A0 address of the parameter block
Registers on exit
D0 result code
RESULT CODES
noErr 0 No error
writErr –20 Driver can’t respond to read requests
badUnitErr –21 Reference number out of range or not in use
unitEmptyErr –22 DCE points to null driver
notOpenErr –26 Driver isn’t open
abortErr –27 Write aborted by KillIO
SEE ALSO
For information about the high-level routine for writing to device drivers, see the previous section, which describes the FSWrite function.
Controlling and Monitoring Devices
You can use either the Control or PBControl function to send control information to a device driver, and you can use the Status or PBStatus function to obtain status information to a device driver. The Device Manager provides the KillIO and PBKillIO functions for terminating all requests in a driver’s request queue.
The PBControl, PBStatus, and PBKillIO functions use the additional control and status fields of the parameter block, as described on page 1-16.
1Control
You can use the Control function to send control information to a device driver.
FUNCTION Control (refNum: Integer; csCode: Integer;
csParamPtr: Ptr): OSErr;
refNum Contains the reference number identifying the driver.
csCode Contains a driver-dependent code specifying the type of information sent.
csParamPtr Contains a pointer to the actual control information.
DESCRIPTION
The Control function sends information to the device driver specified by the reference number in the refNum parameter. The value you pass in the csCode parameter and the type of information pointed to by the csParamPtr parameter depend on the driver being called. For more information, see the specific chapters for the standard drivers.
The Control function is a high-level version of the low-level PBControl function. Use the PBControl function, described in the next section, if you need to specify a drive number or if you want the control request to be asynchronous.
SPECIAL CONSIDERATIONS
The Control function does not move memory. However, you should be sure the device driver does not move memory in response to a control request before you call this function at interrupt time.
RESULT CODES
noErr 0 No error
controlErr –17 Driver can’t respond to this control request
badUnitErr –21 Reference number out of range or not in use
unitEmptyErr –22 DCE points to null driver
notOpenErr –26 Driver isn’t open
abortErr –27 Control request aborted by KillIO
SEE ALSO
For information about the low-level routine for controlling device drivers, see the next section, which describes the PBControl function.
1PBControl
You can use the PBControl function to send control information to a device driver.
FUNCTION PBControl (paramBlock: ParmBlkPtr;
async: Boolean): OSErr;
paramBlock Contains a pointer to the parameter block.
async Specifies to the Device Manager whether the request is asynchronous.
You specify values and receive return values in a Device Manager parameter block.
<symbol\>\xae ioCompletion ProcPtr Pointer to completion routine.
The PBControl function sends information to the device driver specified by the ioCRefNum field. The value you pass in the csCode field and the type of information in the csParamPtr parameter depend on the driver being called. For more information, see the specific chapters for the standard drivers.
SPECIAL CONSIDERATIONS
The PBControl function does not move memory. However, you should be sure the device driver does not move memory in response to a control request before you call this function at interrupt time.
ASSEMBLY-LANGUAGE INFORMATION
The trap macro for the PBControl function is _Control ($A004). Set bit 10 of the trap word to execute this routine asynchronously. Set bit 9 to execute it immediately.
You must setup register A0 with the address of the parameter block. When _Control returns, register D0 contains the result code. Register D0 is the only register affected by this routine.
Registers on entry
A0 address of the parameter block
Registers on exit
D0 result code
RESULT CODES
noErr 0 No error
controlErr –17 Driver can’t respond to this control request
badUnitErr –21 Reference number out of range or not in use
unitEmptyErr –22 DCE points to null driver
notOpenErr –26 Driver isn’t open
abortErr –27 Control request aborted by KillIO
SEE ALSO
For information about the high-level routine for controlling device drivers, see the previous section, which describes the Control function.
1Status
You can use the Status function to obtain status information from a device driver.
FUNCTION Status (refNum: Integer; csCode: Integer;
csParamPtr: Ptr): OSErr;
refNum Contains the reference number identifying the driver.
csCode Contains a driver-dependent code specifying the type of information requested.
csParamPtr Contains a pointer to the status information received.
DESCRIPTION
The Status function returns information about the device driver having the reference number specified by the refNum parameter. The value you pass in the csCode parameter, and the received information pointed to by the csParamPtr parameter depend on the driver being called. For more information, see the specific chapters for the standard drivers.
The Status function is a high-level version of the low-level PBStatus function. Use the PBStatus function if you need to specify a drive number or if you want the status request to be asynchronous.
SPECIAL CONSIDERATIONS
The Status function does not move memory. However, you should be sure the device driver does not move memory in response to a status request before you call this function at interrupt time.
RESULT CODES
noErr 0 No error
statusErr –18 Driver can’t respond to this status request
badUnitErr –21 Reference number out of range or not in use
unitEmptyErr –22 DCE points to null driver
notOpenErr –26 Driver isn’t open
abortErr –27 Status request aborted by KillIO
SEE ALSO
For information about the low-level routine for monitoring device drivers, see the next section, which describes the PBStatus function.
1PBStatus
You can use the PBStatus function to obtain status information from a device driver.
FUNCTION PBStatus (paramBlock: ParmBlkPtr;
async: Boolan): OSErr;
paramBlock Contains a pointer to the parameter block.
async Specifies to the Device Manager whether the request is asynchronous.
You specify values and receive return values in a Device Manager parameter block.
<symbol\>\xae ioCompletion ProcPtr Pointer to completion routine.
The PBStatus function returns information about the device driver having the reference number specified by the ioCRefNum field. The value you pass in the csCode field and the information received in the csParam field depend on the driver being called. For more information, see the specific chapters for the standard drivers.
SPECIAL CONSIDERATIONS
The PBStatus function does not move memory. However, you should be sure the device driver does not move memory in response to a status request before you call this function at interrupt time.
ASSEMBLY-LANGUAGE INFORMATION
The trap macro for the PBStatus function is _Status ($A005). Set bit 10 of the trap word to execute this routine asynchronously. Set bit 9 to execute it immediately.
You must setup register A0 with the address of the parameter block. When _Status returns, register D0 contains the result code. Register D0 is the only register affected by this routine.
Registers on entry
A0 address of the parameter block
Registers on exit
D0 result code
RESULT CODES
noErr 0 No error
statusErr –18 Driver can’t respond to this status request
badUnitErr –21 Reference number out of range or not in use
unitEmptyErr –22 DCE points to null driver
notOpenErr –26 Driver isn’t open
abortErr –27 Status request aborted by KillIO
SEE ALSO
For information about the high-level routine for monitoring device drivers, see the previous section, which describes the Status function.
1KillIO
You can use the KillIO function to terminate all current and pending I/O with a device driver.
FUNCTION KillIO (refNum: Integer): OSErr;
refNum Contains the reference number identifying the driver.
DESCRIPTION
The KillIO function stops any current I/O request being processed by the driver indicated by the ioRefNum field and removes all pending I/O requests from the request queue for that driver. The Device Manager calls the completion routine for each pending I/O request with the ioResult field of each request equal to the result code abortErr.
The Device Manager passes KillIO requests to a driver only if the driver is open and enabled for control calls.
The KillIO function terminates all pending I/O for a driver, including I/O initiated by other applications.<36pt\>\x12 <8bat\>s
SPECIAL CONSIDERATIONS
The KillIO function does not move memory. However, you should be sure the device driver does not move memory in response to this request before you call this function at interrupt time.
RESULT CODES
noErr 0 No error
statusErr –18 Driver can’t respond to this status request
badUnitErr –21 Reference number out of range or not in use
unitEmptyErr –22 DCE points to null driver
notOpenErr –26 Driver isn’t open
SEE ALSO
For information about the low-level routine for terminating pending requests for a driver, see the next section, which describes the PBKillIO function.
1PBKillIO
You can use the PBKillIO function to terminate all current and pending I/O with a device driver.
FUNCTION PBKillIO (paramBlock: ParmBlkPtr;
async: Boolean) : OSErr;
paramBlock Contains a pointer to the parameter block.
async Specifies to the Device Manager whether the request is asynchronous. You should always set this parameter to FALSE.
You specify values and receive return values in a Device Manager parameter block.
<symbol\>\xae ioCompletion ProcPtr Pointer to completion routine
<symbol\>\xac ioResult OSErr Result code
<symbol\>\xae ioCRefNum Integer Driver reference number
DESCRIPTION
The PBKillIO function stops any current request being processed by the driver indicated by the ioCRefNum field and removes all pending requests from the driver’s request queue. The Device Manager calls the completion routine for each pending request with the ioResult field of each request equal to the result code abortErr.
The Device Manager always executes the PBKillIO routine immediately; that is, it never places a PBKillIO request in a driver’s request queue. However, you should not call this routine immediately—always call the PBKillIO routine synchronously.
Note that the Device Manager passes PBKillIO requests to a driver only if the driver is open and enabled for control calls.
The PBKillIO function terminates all pending requests for a driver, including requests initiated by other applications.<36pt\>\x12 <8bat\>s
SPECIAL CONSIDERATIONS
The PBKillIO function does not move memory. However, you should be sure the device driver does not move memory in response to this request before you call this function at interrupt time.
ASSEMBLY-LANGUAGE INFORMATION
The trap macro for the PBKillIO function is _KillIO ($A006). You must setup register A0 with the address of the parameter block. When _KillIO returns, register D0 contains the result code. Register D0 is the only register affected by this routine.
Registers on entry
A0 address of the parameter block
Registers on exit
D0 result code
RESULT CODES
noErr 0 No error
statusErr –18 Driver can’t respond to this status request
badUnitErr –21 Reference number out of range or not in use
unitEmptyErr –22 DCE points to null driver
notOpenErr –26 Driver isn’t open
SEE ALSO
For information about the high-level routine for terminating pending requests for a driver, see the previous section, which describes the KillIO function.
Summary of the Device Manager
This section lists the definitions and declarations provided in this chapter. You can find advanced Device Manager information in the “Summary” section of the chapter “Writing Your Own Device Driver,” in this book.
ioVRefNum : Integer; {volume reference or drive number}
CASE ParamBlkType OF
ioParam:
(ioRefNum: Integer; {driver reference number}
ioVersNum: SignedByte; {not used}
ioPermssn: SignedByte; {read/write permission}
ioMisc: Ptr; {not used}
ioBuffer: Ptr; {pointer to data buffer}
ioReqCount: LongInt; {requested number of bytes}
ioActCount: LongInt; {actual number of bytes}
ioPosMode: Integer; {positioning mode}
ioPosOffset: LongInt); {positioning offset}
cntrlParam:
(ioCRefNum: Integer; {driver reference number}
csCode: SignedByte; {type of request}
csParam: ARRAY[1..10] OF Integer);
{control or status info}
END;
END;
Routines
Opening and Closing Device Drivers
FUNCTION OpenDriver (name: Str255;
VAR refNum: Integer): OSErr;
FUNCTION PBOpen (paramBlock: ParmBlkPtr;
async: Boolean): OSErr;
FUNCTION OpenSlot (paramBlock: ParmBlkPtr;
async: Boolean): OSErr;
FUNCTION CloseDriver (refNum: Integer): OSErr;
FUNCTION PBClose (paramBlock: ParmBlkPtr;
async: Boolean): OSErr;
Reading From and Writing To Device Drivers
FUNCTION FSRead (refNum: Integer;
VAR count: LongInt;
buffPtr: Ptr): OSErr;
FUNCTION PBRead (paramBlock: ParmBlkPtr;
async: Boolean): OSErr;
FUNCTION FSWrite (refNum: Integer:
VAR count: LongInt;
buffPtr: Ptr): OSErr;
FUNCTION PBWrite (paramBlock: ParmBlkPtr;
async: Boolean): OSErr;
Controlling and Monitoring Device Drivers
FUNCTION Control (refNum: Integer;
csCode: Integer;
csParamPtr: Ptr): OSErr;
FUNCTION PBControl (paramBlock: ParmBlkPtr;
async: Boolean): OSErr;
FUNCTION Status (refNum: Integer;
csCode: Integer;
csParamPtr: Ptr): OSErr;
FUNCTION PBStatus (paramBlock: ParmBlkPtr;
async: Boolean): OSErr;
FUNCTION KillIO (refNum: Integer): OSErr;
FUNCTION PBKillIO (paramBlock: ParmBlkPtr;
async: Boolean): OSErr;
Result Codes
noErr 0 No Error
controlErr –17 Driver can’t respond to this control request
statusErr –18 Driver can’t respond to this status request
readErr –19 Driver can’t respond to read requests
writErr –20 Driver can’t respond to write requests
badUnitErr –21 Bad reference number
unitEmptyErr –22 Bad reference number
openErr –23 Driver can’t perform requested reading or writing
dInstErr –26 Couldn’t find driver in resource file
dRemovErr –26 Attempt to remove an open driver
notOpenErr –26 Driver isn’t open
abortErr –27 Request aborted by KillIO
ioErr –36 Data doesn’t match in read-verify mode
Assembly-Language Information
Device Manager Parameter Block
0 qLink used internally by the Device Manager
4 qType used internally by the Device Manager
6 ioTrap used internally by the Device Manager
8 ioCmdAddr used internally by the Device Manager
<symbol\>\xae 12 ioCompletion completion routine
<symbol\>\xac 16 ioResult result code
<symbol\>\xae 18 ioNamePtr driver name
<symbol\>\xae 22 ioVRefNum drive number
<symbol\>\xae 24 ioRefNum driver reference number
26 ioVersNum not used
<symbol\>\xae 28 ioPermssn read/write permission
30 ioMisc not used
<symbol\>\xae 32 ioBuffer pointer to data buffer
<symbol\>\xae 36 ioReqCount requested number of bytes
<symbol\>\xac 40 ioActCount actual number of bytes
<symbol\>\xae 44 ioPosMode positioning mode
<symbol\>\xab 46 ioPosOffset positioning offset
<symbol\>\xae 24 ioCRefNum driver reference number
<symbol\>\xae 26 csCode type of control or status request
<symbol\>\xab 28 csParam control or status information
28 ioMix reserved for use by slot driver’s open routine
<symbol\>\xae 32 ioFlags determines number of additional fields for OpenSlot
<symbol\>\xae 34 ioSlot slot number
<symbol\>\xae 35 ioId slot resource ID
<symbol\>\xae 34 ioSEBlkPtr pointer to external parameter block
Trap Macros
Trap Macro Trap Word
_Open $A000
_Close $A001
_Read $A002
_Write $A003
_Control $A004
_Status $A005
_KillIO $A006
Writing Your Own
Device Driver
Writing a Device Driver2-3
How the Device Manager Works2-3
Creating a Driver Resource2-5
Responding to the Device Manager2-10
Entering and Exiting From Driver Subroutines2-10
Writing the Open and Close Subroutines2-11
Writing the Prime Subroutine2-14
Writing the Control and Status Subroutines2-15
Handling I/O Asynchronously2-18
Installing the Driver2-19
Writing a Chooser-Compatible Device Driver2-22
How the Chooser Works2-22
Creating a Chooser Extension File2-25
Creating a Device Package2-27
Responding to the Chooser2-29
Allocating private storage2-32
Writing a Desk Accessory2-33
How Desk Accessories Work2-33
Creating a Driver Resource for a Desk Accessory2-34
Opening and Closing a Desk Accessory2-34
Responding to Events2-35
Reference2-36
Data Structures2-36
The Extended Device Control Entry2-37
Routines2-38
Resources2-41
Summary2-43
2Writing Your Own Device Driver
This chapter describes how to write a device driver, how your device driver can use the Chooser, and how to make your device driver into a desk accessory.
Although this chapter describes some of the internal mechanisms of the Device Manager, you do not need to read this chapter if you want to use the Device Manager to communicate with an already-existing device driver. See the chapter “The Device Manager” instead.
If you do want to write your own device driver, or just learn about how the Device Manager interacts with device drivers, you should first read the chapter “The Device Manager” and then read this chapter.
This chapter shows how you can
n create a device driver that responds to Device Manager requests
n provide a user interface for your driver with the Chooser
n create a desk accessory
You should read the first section of this chapter, which describes how to write a basic device driver, before reading the sections on the Chooser or desk accessories.
Writing a Device Driver
This section shows you how to write a basic device driver—one that can respond to Device Manager requests. You should read this section before reading “Writing a Chooser-Compatible Device Driver” on page 2-21 or “Writing a Desk Accessory” on page 2-31.
To write a device driver, you need to know
n how the Device Manager opens drivers, maintains data structures about them, and communicates with them
n how to create a driver resource
n how the code in your driver resource should respond to Device Manager requests
The next few sections examine these topics.
How the Device Manager Works
The Device Manager communicates with device drivers by calling one of five driver subroutines: Open, Prime, Control, Status, and Close. All drivers must have an Open and Close subroutine; the Prime, Control, and Status subroutines are optional.
Each driver subroutine is responsible for handling certain types of Device Manager requests.
The Device Manager routines are listed by their actual names. The corresponding driver subroutine names are descriptive names. You can choose any name for your actual driver routines—the Device Manager locates them using offsets you provide.<36pt\>\x12 <8bat\>u
When an application or another manager calls the OpenDriver function, the Device Manager searches the unit table to see if a driver with the specified name is already open. If no open driver has a matching name, the Device Manager opens the driver resource with the specified name. To open a driver from a resource, the Device Manager
n loads the driver code from the resource into memory
n creates a device control entry for it, filling it in with values from the header of the driver resource,
n installs the device control entry in the unit table at a location determined by the driver resource ID
n calls the driver’s Open subroutine.
The header of the driver resource contains information about the driver such as which driver subroutines are implemented and where the subroutines are. See “Creating a Driver Resource” on page 2-5 for the format of the driver header.
Unlike the OpenDriver function, the PBOpen and OpenSlot functions expect the driver to be already installed. These functions search the unit table for the driver’s device control entry and call the driver’s Open subroutine.
If you use the PBOpen or OpenSlot function to open your driver, you are responsible for creating the device control entry and installing it in the unit table. Even if you use the OpenDriver function to install your driver, you are responsible for finding an empty space in the unit table, which may require allocating more memory for it. The section “Installing the Driver” on page 2-18 discusses the device control entry, the unit table, and how you can properly install your driver.
To allow asynchronous requests, the Device Manager maintains a driver request queue for each open driver. A driver request queue is a standard Operating System queue, as described in the chapter “Operating System Utilities” in the Inside Macintosh: Operating System volume.
When an application or another manager calls the PBRead, PBWrite, PBStatus, or PBControl routine, the Device Manager places the parameter block at end of the driver’s request queue. The high-level versions of these routines create a parameter block (filling the fields with the values of the parameters sent to routine where possible and using default values for the rest) and add it to the request queue. As previously-queued requests are satisfied, the parameter block moves forward in the request queue. When the parameter block is at the beginning of the request queue, the Device Manager calls the appropriate driver subroutine and passes it a pointer to the parameter block and a pointer to the driver’s device control entry.
For reading and writing requests, the Device Manager calls the Prime subroutine, described in “Writing the Prime Subroutine” on page 2-13. This subroutine can execute synchronously, completing the requested reading or writing before returning control to the Device Manager, or asynchronously, beginning the requested transaction but returning control to the Device Manager before the completing it. If the driver’s Prime routine can execute asynchronously, the driver must use some mechanism to regain control of the processor and complete the request. Typically these drivers provide interrupt handlers that respond to interrupts from the driver’s device and notify the Device Manager when the transaction is complete. See “Handling I/O Asynchronously” on page 2-17 for more details.
The Device Manager handles controlling and monitoring requests in the same way as reading and writing requests, except that for controlling requests it calls the Control subroutine and for monitoring requests it calls the Status subroutine. The section “Writing the Control and Status Subroutines” on page 2-15 shows how to provide these subroutines for your driver.
The Device Manager responds to KillIO requests by removing the parameter blocks from the queue, calling their completion routines with the result code abortErr, and then calling the drivers Control subroutine with a value of killCode for the csCode parameter. You can find information on handling KillIO requests in “Writing the Control and Status Subroutines” on page 2-15.
In response to a closing request, the Device Manager queues the parameter block, making one if necessary. Since closing requests cannot be asynchronous, the Device Manager sends each queued request to the driver. Since the last request is the closing request, the Device Manager ultimately calls the Close subroutine. When the driver indicates it has satisfied the closing request, the Device Manager unlocks the device control entry and the driver code. Note that the Device Manager does not dispose of the device control entry or even remove it from the unit table.
The section “Writing the Open and Close Subroutines” on page 2-11 shows how your driver can respond to both opening and closing requests.
Creating a Driver Resource
You will probably want to store your driver in a driver resource, although if you are writing a driver for a slot device you might want to store your driver in the declaration ROM of the expansion card (see Designing Cards and Drivers for the Macintosh Family for more details). Storing your driver in a driver resource allows the OpenDriver function to load your driver code into memory and install a device control entry for your driver in the unit table.
Like all resources, your driver resource has a resource type, a resource ID, a resource name, and resource attributes:
n The resource type must be 'DRVR'.
n The resource ID determines where in the unit table the OpenSlot function installs the driver’s device control entry. Unfortunately, you must choose the resource ID when creating your driver resource and you cannot know which unit numbers will be available until you open your driver. Therefore, your driver-opening routine must find an empty location in the unit table and change the resource ID accordingly. The section “Installing the Driver” on page 2-18 discusses appropriate values for the resource ID.
n The resource name should be the same as the driver name so that the OpenDriver function can find the driver resource. A driver name consists of a period (.) followed by any sequence of 1 to 254 printing characters. The Device Manager ignores case (but not diacritical marks) when comparing names.
n The resource attributes of your driver resource depend on your driver. A typical driver might have these attributes: locked, since most drivers contain code that is called at interrupt time; in the system heap, so that the driver exists over launches of applications; and preloaded, which makes resource loading slightly more efficient.
A driver resource has two parts:
n a driver header that contains information about the driver
n the routines that do the work of the driver
The driver header contains a few words of flags and other data, offsets to the driver’s routines, and an optional driver name. Figure 2-1 shows the format of a driver header.
The format of a driver header
drvrFlags Contains flags in its high-order byte that specify certain characteristics of the driver. You can use the constants in Listing 2-1 to index the flags in this field.
drvrDelay Indicates number of ticks between periodic actions.
drvrEMask Used for desk accessories. See “Writing a Desk Accessory” on page 2-31 for information about this field.
drvrMenu Used for desk accessories. See “Writing a Desk Accessory” on page 2-31 for information about this field
drvrOpen Contains an offset to the Open driver subroutine.
drvrPrime Contains an offset to the Prime driver subroutine.
drvrCtl Contains an offset to the Control driver subroutine.
drvrStatus Contains an offset to the Status driver subroutine.
drvrClose Contains an offset to the Close driver subroutine.
drvrName Contains the driver name. You can use uppercase and lowercase letters when naming your driver, but the first character should be a period—.YourDriver, for example.
See the section “Entering and Exiting From Driver Subroutines” on page 2-9 for more information about the subroutine offsets.
Your driver routines, which follow the driver header, must be aligned on a word boundary.<36pt\>\x12 <8bat\>u
The index constants for the drvrFlags field
dReadEnable EQU 0 ;set if driver can respond to Read requests
dWritEnable EQU 1 ;set if driver can respond to Write requests
dCtlEnable EQU 2 ;set if driver can respond to Control requests
dStatEnable EQU 3 ;set if driver can respond to Status requests
dNeedGoodbye EQU 4 ;set if driver needs to be called before the
; application heap is initialized
dNeedTime EQU 5 ;set if driver needs time for performing
; periodic tasks
dNeedLock EQU 6 ;set if driver will be locked in memory as
; soon as it's opened
The first four flags, which occupy bits 0–3 of the high-order byte (bits 8–11 of the drvrFlags word), indicate which Device Manager requests the driver’s routines can respond to. The next section, “Responding to the Device Manager,” on page 2-9 describes these routines in detail.
Drivers in the application heap are lost when the heap is reinitialized. If you set the dNeedGoodbye flag, the Device Manager calls your driver before the heap is reinitialized so that you can perform any clean-up actions. See “Writing the Control and Status Subroutines” on page 2-15 for more details.
You set the dNeedTime flag of the drvrFlags word if your device driver needs to perform some action periodically. For example, a network driver may want to poll its input buffer every 5 seconds to see if it has received any messages. The value of the drvrDelay word indicates how many ticks should pass between periodic actions. For example, a value of 0 in the drvrDelay word indicates that the action should happen as often as possible, a value of 1 means it should happen every sixtieth of a second, a value of 2 means at most every thirtieth of a second, and so on. Whether the action actually occurs this frequently depends on how often the application calls the Desk Manager procedure SystemTask. See “Writing the Control and Status Subroutines” on page 2-15 for more details.
If you do not want your driver to depend on applications to call SystemTask, you can still perform actions periodically by installing a VBL task, a Deferred Task Manager task, a Time Manager task, or a Notification Manager task. For more information, see the chapters corresponding to these managers.<36pt\>\x12 <8bat\>u
You need to set the dNeedLock flag if your driver’s code should be locked in memory. In particular, you need to set this flag in these two cases:
n If any part of your driver’s code can be called at interrupt time. At interrupt time, the heap may not be in a consistent state. If your driver is not locked, the system could be in the process of relocating it in memory.
n If your driver provides the Operating System with a pointer to any part of its code. For example, if your driver uses the Device Manager to call another driver, you might provide the Device Manager with a pointer to completion routine. If that completion routine is in your driver code, your driver code must be locked. Otherwise, that pointer might not be valid by the time the Device Manager calls the completion routine.
You can create your driver header in these ways:
n You can use a resource compiler. See “Resources” on page 2-38 for the Rez format of the driver resource.
n You can use the DC instruction, as shown in Listing 2-2, to position the header information directly in your assembly language code.
An assembly-language driver header
DHeader
DFlags DC.B 0 ;set by DRVROpen
DC.B 0 ;set by DRVROpen
DDelay DC.W 0 ;none
DEMask DC.W 0 ;DA event mask
DMenu DC.W 0 ;no menu
DC.W DOpen - DHeader ;offset to Open
DC.W DPrime - DHeader ;offset to Prime
DC.W DControl - DHeader ;offset to Control
DC.W DStatus - DHeader ;offset to Status
DC.W DClose - DHeader ;offset to Close
Name DC.B '.DRIVER' ;name of driver
ALIGN 2 ;word align
In this example, the drvrFlags word is cleared to 0—the actual flags are set in the DRVROpen routine, defined in “Writing the Open and Close Subroutines” on page 2-11. The drvrDelay field is set to 0 and the drvrEMask and drvrMenu fields are set to 0, as this driver is not a desk accessory. The next five fields give offsets to the driver subroutines, defined in the next section, “Responding to the Device Manager.” The header ends with the driver name and word alignment.
Responding to the Device Manager
The Device Manager calls a driver subroutine by setting up registers and jumping to the address indicated by the subroutine’s offset in the driver header.
n Register A0 contains a pointer to the parameter block.
n Register A1 contains a pointer to the device control entry.
This interface requires you to use some assembly language when writing a driver. However, you can write your driver subroutines in a high-level language if you provide an assembly-language dispatching mechanism that acts as an interface between the Device Manager and your driver subroutines.
The next few sections discuss how you can provide a dispatching routine and how you can implement your driver subroutines in a high-level language.
Entering and Exiting From Driver Subroutines
Listing 2-3 shows an assembly-language routine that you can use an interface between the Device Manager and your high-level language driver subroutines. In this example, each driver subroutine (which the Device Manager locates using the offsets defined in Listing 2-2) pushes the address of its corresponding high-level language subroutine and then branch to the dispatching routine.
Entering and exiting from driver subroutines
DOpen pea DRVROPEN
bra.s DRVRDispatch
DPrime pea DRVRPRIME
bra.s DRVRDispatch
DControl pea DRVRCONTROL
bra.s DRVRDispatch
DStatus pea DRVRSTATUS
bra.s DRVRDispatch
DClose pea DRVRCLOSE ;and fall thru to DRVRDispatch
DRVRDispatch
movem.l a0/a1, -(sp) ;save registers (for IODone)
clr.w -(sp) ;save room for result
move.l a0, -(sp) ;push paramblock ptr on stack
move.l a1, -(sp) ;push dce ptr on stack
movea.l $12(sp), a0 ;load address of routine into a0
The DRVRDispatch routine begins by saving the A0 and A1 registers, clearing room on the stack for the result code, and pushing the parameters on the stack and jumping to the appropriate driver subroutine.
When the driver subroutine returns, the DRVRDispatch routine moves the result code to register D0, restores the A0 and A1 registers, clears the subroutine address from the stack, and then returns control to the Device Manager in one of two ways:
n With an RTS instruction. You do not want the Device Manager to remove to the request from the driver request queue. In particular, the DRVRDispatch routine returns with an RTS instruction from immediate requests (which the Device Manager never adds to the queue) and from incomplete requests that the driver is executing asynchronously (which should remain in the queue until the driver completes them). The driver subroutines return a result code of 1 to indicate that the request is still incomplete.
n By jumping to the IODone routine. This routine, described in detail on page 2-38, indicates to the Device Manager that the request is complete. The Device Manager will remove the request from the driver request queue and call the completion routine.
The next few sections discuss how to write your driver subroutines.
Writing the Open and Close Subroutines
You must provide both an Open subroutine and a Close subroutine for your driver. The Device Manager always executes these routines as synchronous requests and they should return by means of an RTS instruction.
Your Open routine must allocate any private storage that your driver requires and store a handle to this storage in the dCtlStorage field of the device control entry.
After allocating private storage, you should initialize it and do any further preparation required by your driver.
You might also install interrupt handlers, change interrupt vectors, and store a pointer to the device control entry somewhere in local storage for the interrupt handlers to use. The section “Handling I/O Asynchronously” on page 2-17 discusses interrupt handling in more detail.
The DrvrDispatch routine in Listing 2-3 returns the result codes of the driver subroutines in register D0. However, upon return from the Open subroutine, the Device Manager sets register D0 to 0; therefore, your Open routine should place the result code in the ioResult field of the parameter block.
Listing 2-4 shows a sample Open subroutine, DRVROpen. The DRVROpen function begins by setting the flags of the device control entry (see Listing 2-2 on page 2-9) and checking whether the driver is already open (by examining the contents of the dCtlStorage field of the device control entry). If the driver is not already open, the DRVROpen function allocates memory for private storage. The private storage of the driver in this example contains two fields: the numBeeps field stores a value of type LongInt, and the buffer field stores a buffer of 255 bytes. The Prime, Control, and Status subroutines described in the next two sections use these fields.
If the DRVROpen function fails to allocate memory for private storage, it returns with an openErr result code. The DRVRDispatch routine returns this result code in register D0, which notifies the Device Manager that the driver did not open. If the memory allocation succeeds, the DRVROpen function places a noErr result code in the ioResult field of the parameter block.
Your Close subroutine must reverse the effects of your Open subroutine by releasing any used memory, removing interrupt handlers, removing any VBL or Time Manager tasks, and replacing changed interrupt vectors.
If you want to save any information about the operational state of the driver until the next time the driver is opened, you should store this information in a relocatable block of memory pointed to by the dCtlStorage field, because the Device Manager does not dispose of the device control entry when a driver is closed.
Listing 2-5 shows a sample Close subroutine, DRVRClose. Since the DRVROpen function for this sample driver allocated private storage, and the driver doesn’t need to store any information until the next time its opened, the DRVRClose function simply disposes the private storage.
Sample Close driver subroutine
FUNCTION DRVRClose (VAR pb: ParamBlockRec;
VAR dce: DCtlEntry): OSErr;
BEGIN
IF (dce.dCtlStorage <> nil) THEN
BEGIN
DisposHandle(dce.dCtlStorage);
dce.dCtlStorage := nil;
END;
DRVRClose := NOErr;
END;
Writing the Prime Subroutine
Your Prime routine implements the I/O requests. You can write your Prime subroutine to execute synchronously or asynchronously. A synchronous Prime subroutine completes an entire I/O request before returning to the Device Manager. An asynchronous Prime subroutine can begin an I/O transaction but return to the Device Manager before the request is complete. In this case, the I/O request continues to be executed, typically when more data is available, by other routines such as interrupt handlers or completion routines. The section “Handling I/O Asynchronously” on page 2-17 discusses how to complete an asynchronous Prime subroutine.
Notice the difference between asynchronous requests and asynchronous subroutines. The Device Manager places asynchronous requests in the request queue and returns control to the application right away. Asynchronous subroutines are capable of satisfying a large request in small pieces, one piece at a time.<36pt\>\x12 <8bat\>u
The Device Manager indicates whether it is requesting a Read or a Write operation by placing one of the following constants in the low-order byte of the ioTrap field of the parameter block:
aRdCmd EQU 2 ;Read operation requested
aWrCmd EQU 3 ;Write operation requested
The Device Manager provides two routines—Fetch and Stash—that provide low-level support for reading and writing characters to and from data buffers. Use of these routines is optional. The section “Routines” on page 2-36 describes these routines in detail.
The Fetch and Stash routines update the ioActCount field of the parameter block. If you do not use these routines, you are responsible for updating this field.
If your driver serves a block device, you should update the dCtlPosition field of the device control entry.
Listing 2-4 shows a sample Prime subroutine, DRVRPrime. The DRVRPrime function allows applications to read and write up to 255 bytes of data to its private data buffer.
The DRVRPrime function checks the requested byte count and lowers it if it is greater than the size of the private buffer. Then, the function examines the low-order byte of the ioTrap field of the parameter block to determine whether the Device Manager is requesting a read operation or a write operation. The function then moves the requested number of from its private storage to the buffer designated by the parameter block for a read operation, or from the designated buffer to its private storage for a write operation. (A real driver would probably send the data to or request the data from a hardware device, instead of storing the data itself.)
The DRVRPrime function then updates the ioActCount field appropriately.
Sample Prime driver subroutine
FUNCTION DRVRPrime (VAR pb: ParamBlockRec;
VAR dce: DCtlEntry): OSErr;
VAR
dStore : MyDriverGlobalsHdl;
callType : Integer;
numBytes : LongInt;
BEGIN
DRVRPrime := NoErr;
IF (dce.dCtlStorage <> nil) THEN
BEGIN
dStore := MyDriverGlobalsHdl(dce.dCtlStorage);
numBytes := pb.ioReqCount;
IF numBytes > 256 THEN
numBytes := 256;
callType := BAND($00FF,pb.ioTrap);
CASE callType OF
aRdCmd: BlockMove(@dStore^^.buffer,
pb.ioBuffer,numBytes);
aWrCmd: BlockMove(pb.ioBuffer,
@dStore^^.buffer,numBytes);
END;
pb.ioActCount := numBytes;
END
ELSE
DRVRPrime := mFulErr;
END;
Writing the Control and Status Subroutines
Like the Prime subroutine, the Control and Status subroutines that you write can execute synchronously or asynchronously.
The Device Manager passes information to the Control routine in the csCode and csParam fields of the parameter block. The csCode field specifies the type of control information and the csParam field, which is up to 22 bytes long, contains the actual control information. The Device Manager reserves some values for the csCode parameter to indicate certain types of control requests.
You can identify these requests by checking the csCode field for these constant values:
Constant name Value Meaning
killCode 1 KillIO requested
goodBye -1 Heap being reinitialized
accRun 65 Time for periodic action
When the Device Manager receives a KillIO request, it removes every parameter block from the driver request queue. If your driver responds to any requests asynchronously, the part of your driver that completes requests begun by the driver subroutines (for example, an interrupt handler) might expect the parameter block for the pending request to be at the head of the request queue. The Device Manager notifies your driver of KillIO requests so that you can take the appropriate actions to stop work on the pending request. You should be certain you return control to the Device Manager by means of an RTS instruction and not by jumping to the IODone routine.
If you set the dNeedGoodbye flag in the drvrFlags word of your device header, the Device Manager will call your Control routine with the value goodBye in the csCode parameter before the heap is reinitialized. You can respond by performing any clean-up actions necessary before heap reinitialization.
If you set the dNeedTime flag in the drvrFlags word of your device header, the Device Manager will call your Control routine with the value accRun in the csCode parameter periodically.
You can interpret other values of the csCode field as suited for your driver. Your Control routine should accept this control information and manipulate the device as requested.
Listing 2-7 shows a sample Control subroutine, DRVRControl. The DRVRControl function allows applications to specify a number of times for the driver to produce a system beep. The driver stores the requested number in its private storage.
The DRVRControl function interprets the value
CONST beepIt = 100;
in the csCode field to indicate a request for system beeps. You would define this constant in the constant definition part of your Pascal unit.
The DRVRControl function examines the csCode field of the parameter block for the beepIt value. If it finds this value, the function examines the csParam field for the number of beeps requested, stores the requested number in private storage, and produces the system beeps.
Sample Control subroutine
FUNCTION DRVRControl (VAR pb: ParamBlockRec;
VAR dce: DCtlEntry): OSErr;
VAR
dStore : MyDriverGlobalsHdl;
beepTimes : Integer;
BEGIN
IF (dce.dCtlStorage <> nil) THEN
BEGIN
dStore := MyDriverGlobalsHdl(dce.dCtlStorage);
CASE pb.csCode OF
beepIt: BEGIN
beepTimes := pb.csParam[0];
dStore^^.numBeeps:= dStore^^.numBeeps+beepTimes;
REPEAT
SysBeep(1);
beepTimes := beepTimes - 1;
UNTIL (beepTimes = 0);
END;
END;
DRVRControl := NoErr;
END;
END;
The Status subroutine should work in a similar manner. The Device Manager uses the csCode field to specify the type of status information requested. Your Status routine should be prepared to respond to whatever requests are appropriate for your driver and return the information in the csParam field.
The Device Manager does not reserve any csCode values for the Status subroutine. However, when the Device Manager receives a Status request with a csCode value of 1, it returns a handle to the driver’s device control entry from the unit table. The driver’s Control subroutine never sees this request.
Listing 2-7 shows a sample Status subroutine, DRVRStatus. The DRVRStatus function returns the number of beeps requested by the most recent Control request.
This function interprets the value
CONST getBeeps = 100;
in csCode field to indicate a Status request for number of beeps last requested. You would define this constant in the constant definition part of your Pascal unit.
Sample Status subroutine
FUNCTION DRVRStatus (VAR pb: ParamBlockRec;
VAR dce: DCtlEntry): OSErr;
VAR
dStore : MyDriverGlobalsHdl;
BEGIN
IF (dce.dCtlStorage <> nil) THEN
BEGIN
dStore := MyDriverGlobalsHdl(dce.dCtlStorage);
CASE pb.csCode OF
getBeeps:
BEGIN
pb.csParam[0] := dStore^^.numBeeps;
END;
END;
END;
DRVRStatus := NoErr;
END;
Handling I/O Asynchronously
If you write any of your driver subroutines to execute asynchronously, you must provide a mechanism for your driver to complete the requests.
Some examples of routines that you might use are:
n Completion routines. Your driver subroutine could call another driver to start the data transfer. In this case, you can provide that driver with a completion routine. When the other driver completes the request, the Device Manager executes the completion routine. In the completion routine, you could call the other driver again to execute the next part of the I/O operation. When the entire operation is complete, the completion routine should return by jumping to the IODone routine.
n Interrupt handlers. Your driver might serve a device, such as a slot device, that generates interrupts. An interrupt causes the processor to suspend normal execution, save the address of the next instruction and the processor’s internal status on the stack, and execute an interrupt handler. You can create an interrupt handler that continues an I/O operation when the device signals, by an interrupt, that it is ready to continue. Your interrupt handler must preserve any registers it uses and clear the source of the interrupt. You may want your Open routine to store a handle to your driver’s device control entry in your driver’s local storage. You can get a handle to the device control entry using the GetDCtlEntry function. For more information on Macintosh interrupts and how to install your own interrupt handlers, see the Guide to Macintosh Family Hardware and Designing Cards and Drivers for the Macintosh Family.
n VBL, Time Manager, and Deferred Task Manager tasks. Installing any of these tasks ensures that your driver receives system time at some point in the future. During this time, you can check to see if the I/O operation is ready to continue.
Interrupts can occur while your interrupt handler is executing. When this happens, it’s possible for the system to suspend your interrupt handler for the first interrupt and then reenter your interrupt handler for the second interrupt. Your interrupt handler is reentrant if it handles this situation correctly.
To help ensure that your driver is reentrant, your driver should store a handle to its private storage in the dCtlStorage field of the device control entry, and not use memory within the driver code itself.u
If your driver serves a device on an expansion card, you might want to respond to slot interrupts, or interrupts signalled by devices on expansion cards. When a NuBus card device signals a slot interrupt, the CPU can quickly detect which card requested the interrupt service, but not which device on the card. To determine which device caused the interrupt, the system uses a polling procedure.
If your driver serves a NuBus card device, it should provide a polling routine—a routine that checks if the device it serves caused the current interrupt, and, if so, calls the proper driver code to handle the interrupt. The Slot Manager maintains a queue of these polling routines for each slot. Your driver can install an element in this queue using the Slot Manager routine SIntInstall. You can also remove a queue element with the Slot Manager routine SIntRemove. The chapter “The Slot Manager” in this book gives more information about the SIntInstall and SIntRemove routines.
For more information on slot interrupts and writing drivers for slot devices, see Designing Cards and Drivers for the Macintosh Family.
Installing the Driver
When you have completed your driver resource, you have a number of options for storing it and installing the driver. Two of the most common are:
n Storing the driver resource in an application and having the application install it.
n Storing the driver resource in a system extension file and writing an initialization ('INIT') resource to install it.
In either case, you need to write code to ensure your driver is properly installed and opened before making sending it any requests. You can create a device control entry yourself and install it in the unit table and then use the PBOpen or OpenSlot function to open it, or you can use the OpenDriver function to install and open it.
If you want to install the driver yourself, see the section “Data Structures” on page 2-34 for details about the device control entry data type.
If you want to use the OpenDriver function to install your driver, you are responsible for examining the unit table and changing your driver resource ID so that the OpenDriver function install your driver in an empty location in the unit table. The OpenDriver function uses the following formula to determine a drivers unit number:
The unit table is a 256-byte nonrelocatable block of 64 four-byte spaces that contain handles to device control entries for installed drivers. If needed, the Device Manager automatically expands the unit table to a maximum of 128 entries. The global variable UTableBase contains the base address of the unit table.
For an entry in the unit table to be suitable it must be empty—that is, contain a NIL pointer—and it must not be reserved. Table 2-1 shows a summary list of unit numbers reserved for specific purposes:
Reserved unit numbers
Unit Number Range RefNum Range Purpose
0 through 11 -1 through -12 Serial, Disk, AppleTalk,
Printer Drivers
12 through 31 -13 through -32 Desk Accessories
32 through 39 -33 through -40 SCSI Devices
40 through 47 -41 through -48 Reserved
48 through 127 -49 through -128 Slot and Other Drivers
Listing 2-9 gives a high-level language function for searching the unit table for an appropriate location to install your driver. The driver-opening routine in the chapter “The Device Manager” calls this function and then uses the OpenDriver function to install and open the device driver.
The Chooser is a desk accessory that helps provide a standard user interface for device drivers. It allows device drivers to prompt the user for choices such as which serial port to use, which AppleTalk zone to communicate with, and which LaserWriter to use.
If your device driver can serve different hardware devices or configurations, you may want to use the Chooser to provide an interface for the user to make choices.
You should read the previous section, “How the Device Manager Works,” which begins on page 2-3, before you read this section.
This section describes the Chooser, how it works, and how you can provide resources that set up a Chooser interface and respond to actions from the user.
How the Chooser Works
The Chooser allows users to select which devices they want to use. When the user launches the Chooser desk accessory, the Chooser displays the Chooser window, which contains lists and buttons for making device-related choices. Typically, users select a type of device from the icon list, then select the particular device they want to use from the device list. For AppleTalk devices, they must also select an AppleTalk zone from the zone list. The Chooser window can also display buttons, such as an OK button, and radio buttons, such as the LaserWriter’s background printing On and Off buttons.
Figure 1-4 shows an example Chooser window.
The Chooser window
The Chooser relies heavily on the List Manager for creating, displaying, and manipulating possible user selections in this window. You may want to read the List Manager chapter in the Inside Macintosh: Toolbox volume for more information.
The Chooser does not communicate directly with device drivers; instead, it communicates with device packages. A device package is a resource similar to a driver resource, except a device package responds to Chooser messages instead of Device Manager requests. The device package is responsible for communicating the user’s choices to the device driver.
Device packages are stored in Chooser extension files, which the Chooser expects to find in the System Folder of the user’s startup disk. The Chooser extension file contains a number of resources in addition to the device package resource. These other resources allow you to specify information to the chooser. For example, you can specify
n The device list box label. The Chooser displays this label over the device list.
n Which buttons to use. The Chooser allows the device package to display up to four buttons, called the Left button, the Right button, the On radio button, and the Off radio button.
n The titles and positions of the buttons.
n The radio button label.
n The AppleTalk device type name. The Chooser searches the current AppleTalk zone for devices of this type.
n An AppleTalk Name-Binding Protocol (NBP) retry interval and a timeout count. The Chooser uses this information when searching for AppleTalk devices.
When a user selects the icon corresponding to a particular device package, the Chooser sends messages to that device package by calling the device package as if it were the following function:
FUNCTION Package (message, caller: Integer;
objName, zoneName: StringPtr;
p1, p2: LongInt) : OSErr;
Like the driver subroutine names, the name Package for the device package routine is a descriptive name. You can choose any name for your actual device package routine—the Chooser locates the routine using the device package header you provide. <36pt\>\x12 <8bat\>u
Parameter descriptions
message Identifies the operation to be performed and has one of the following constant values:
initMsg = 11; {user selected this device package}
newSelMsg = 12; {user made new device selections}
fillListMsg = 13; {fill the device list with choices}
getSelMsg = 14; {mark one or more choices selected}
selectMsg = 15; {user made a selection}
deselectMsg = 16; {user cancelled a selection}
terminateMsg = 17; {allows device package to clean up}
buttonMsg = 18; {user selected a button}
The section “Responding to the Chooser” on page 2-27 explains these messages in more detail.
caller Identifies the caller. A value of 1 indicates the Chooser. Values in the range 0 to 127 are reserved; values outside this range may be used by applications.
zoneName Contains name of AppleTalk zone containing the devices in the device list. If the Chooser is being used with the local zone and bit 24 of the flags field of the device package header is not set, the string value is '*'; otherwise, it’s the actual zone name. See the section “Creating a Device Package” on page 2-26 for more information about the package header.
p1 Contains a handle to the List Manager list that contains the device choices displayed in the device list box.
objName Contains other information. The meaning of this parameter depends on the value of the message parameter. See “Responding to the Chooser” on page 2-27 for more information
p2 Contains other information. The meaning of this parameter depends on the value of the message parameter. See “Responding to the Chooser” on page 2-27 for more information
When the user opens the Chooser, the Chooser searches the Extensions folder in the System Folder of the startup disk for Chooser extension files. For each one it finds, it opens the file, fetches the device’s icon, fetches the flags field from the device package header, and closes the file. The Chooser then displays each device’s icon, graying the icons for AppleTalk devices if AppleTalk is not connected.
When the user selects a device package icon that is not grayed, the Chooser reopens the corresponding Chooser extension file and does the following:
1. The Chooser labels the device list box with the device list box label.
2. The Chooser sends the init message to the selected device package.
3. If the selected device package represents a serial printer, the Chooser places in the device list box the two icons that represent the printer port and the modem port serial drivers. When the user makes a selection, the Chooser records the user’s choice in low memory and parameter RAM.
4. If the selected device package represents an AppleTalk device and does not accept fillList messages, the Chooser initiates an asynchronous routine that interrogates the current AppleTalk zone for all devices whose type matches the AppleTalk device type name specified in the Chooser extension file. The asynchronous routine uses the retry interval and the timeout count. As responses arrive, the Chooser updates the device list box.
5. If the selected device package does accept fillList messages, the Chooser sends the fillList message to the device package. The device package responds by filling the device list with the appropriate device choices.
6. To determine which entries in the device list should be selected, the Chooser calls the device package with the getSel message. The device package responds by inspecting the list and setting the selected or unselected state of each entry. The Chooser may send the getSel message frequently; for example, each time a new response to the AppleTalk zone interrogation arrives. The Chooser does not send the getSel message for serial printers; it highlights the icon corresponding to the currently-selected serial port, as recorded in low memory.
7. If the device package allows multiple devices to be active at once, the Chooser sets the appropriate List Manager bits. When the user selects or deselects a device, the Chooser calls the device package with the appropriate message. For packages that do not accept multiple active devices, the Chooser sends the select or deselect message; otherwise, it sends the newSel message. The device package mounts or unmounts the device, if appropriate, and records the user choice.
8. When the user chooses a different device type or closes the Chooser, the Chooser calls the current device package with the terminate message, if the package accepts this kind of message. At this time, the package can clean up, if necessary. The Chooser then calls the UpdateResFile procedure, closes the device resource file, and flushes the system startup volume.
Creating a Chooser Extension File
The Chooser accepts three types of Chooser extension files to identify different kinds of devices:
File type Device type
'PRES' Serial printer
'PRER' Non-serial printer
'RDEV' Other device
You can specify the creator of your device resource file, which allows you to give your device its own icon.
You can include these resources in your device package file:
Resource Type and ID Description
'PACK' –4096 Device package. This resource contains the device
package header and code.
'STR ' –4096 Type name for AppleTalk devices. The Chooser searches
the current Appletalk zone for devices of this type.
'GNRL' –4096 Appletalk information. The first byte of this resource
contains the Name-Binding Protocol (NBP) retry interval,
the second byte contains the timeout count.
'STR ' –4091 List box label. The Chooser labels the device list with this
string after the user has selected the device’s icon.
'STR ' –4087 Radio button label.
'STR ' –4088 Off radio button title.
'STR ' –4089 On radio button title.
'STR ' –4092 Right button title.
'STR ' –4093 Left button title.
'ncrt' –4096 Button positions.
'LDEF' –4096 Alternate list definition procedure. You can supply this
procedure to modify the device list—to include pictures
or icons, for example.
'STR ' –4090 Reserved for use by the Chooser.
You should also include a 'BNDL' resource to give your device type a distinctive icon, because this may be the only way that devices are identified in the Chooser window. The Finder Interface chapter describes the 'BNDL' resource.
The next section, “Creating a Device Package,” discusses the device package resource in more detail, and the section “How the Chooser Works” on page 2-21 describes how the Chooser uses the fields related to AppleTalk.
The Chooser window allows your device package to display two buttons, called the Left button and the Right button because of their default positions. The left button has a double border and is highlighted (the title string is dark, not gray) when one or more devices are selected from the device list. When this button is highlighted, pressing Return or Enter, or double-clicking in the device list are equivalent to clicking the button. The right button has a single border and is always highlighted, and the user can activate it only by clicking it.
The Chooser also allows you to display two radio buttons and a radio button label. These buttons are called the On radio button and the Off radio button because those are the titles the LaserWriter uses, but you can give them whatever titles you want.
You can position these buttons by including a resource of type 'ncrt' with an ID of –4096. The first word in this type of resource specifies the number of rectangles, and the rest of the resource contains the rectangle definitions. The first rectangle positions the left button, the second positions the right button, the third positions the On radio button, and the fourth positions the Off radio button. The fifth rectangle positions the radio button label.
Each rectangle definition is 8 bytes long and contains the rectangle coordinates in the order [top, left, bottom, right]. The default values are [112, 206, 132, 266] for the left button and [112, 296, 132, 356] for the right button. You could use the values [112, 251, 132, 331] to center a single button.
The Chooser uses the List Manager to produce and display the standard device list. You can supply a list definition procedure to modify this list. For example, you might want to include pictures or icons in your list. To do this, you must provide a resource of type 'LDEF' with an ID of –4096. See the List Manager chapter in the Inside Macintosh: Macintosh Toolbox volume for the mechanics of list construction and for the list data structure.
Creating a Device Package
Like a driver resource, a device package has two parts:
n the package header that contains some flags and some other data about the driver
n the package code that responds to Chooser messages
The package header contains a few words of flags and other data and a branch instruction to the package’s Device routine. Figure 2-3 shows the format of a package header.
The format of a package header
Since the Chooser expects the Package routine to be at the beginning of the device package, the first field of the package header should be a BRA.S instruction to the package code.
The device ID is an integer that identifies the device. The version word differentiates versions of the driver code.
The package code should implement the Package function. The section “How the Chooser Works” on page 2-21 gives the interface for this function. The next section, “Responding to the Chooser,” discusses how to implement this function.
The flags field contains information about the device and the device package. Table 2-2 lists the meaning of each bit of the flag word.
Device package flags
Bit Meaning
31 Set if an AppleTalk device
30–29 Reserved (clear to 0)
28 Set if the device package can have multiple instances selected at once
27 Set if the device package uses the Left button
26 Set if the device package uses the Right button
25 Set if no zone name has been saved
24 Set if device package uses actual zone names
23–21 Reserved (clear to 0)
20 Set if device uses the On and Off radio buttons and radio button label
19–17 Reserved (clear to 0)
17 Set if device package accepts the init message
16 Set if device package accepts the newSel message
15 Set if device package accepts the fillList message
14 Set if device package accepts the getSel message
13 Set if device package accepts the select message
12 Set if device package accepts the deselect message
11 Set if device package accepts the terminate message
10–0 Reserved (clear to 0)
Responding to the Chooser
This section gives more details about how your device package should respond when it receives a message from the Chooser.
When the Chooser sends your device package a message, the Chooser extension file is the current resource file, the Chooser window is the current grafPort, and the System Folder of the current startup disk is the default volume. Your device package must preserve all of these.
Table 2-3 lists the Chooser messages and how your package should respond to them.
Chooser messages and their meanings
Message Meaning
init The Chooser sends this message to your package when the user selects the icon representing your package in the icon list. The objName parameter contains a pointer to a data structure that contains a size word followed by four handles to ControlRecord data structures. The size is at least 18 bytes (2 bytes for the size word and 4 bytes for each of the handles). The handles reference the Left and Right buttons and the On and Off radio buttons in that order. Your package can respond to this message by setting up the initial button configuration. To display one of the radio buttons, you must call the ShowControl routine for it. To highlight them, you must call the SetCtlValue routine. See the chapter “The Control Manager” for more information. The p2 parameter is not used.
newSel If your device package allows multiple selections, the Chooser sends this message to your packages when the user changes or adds a selection. The objName and p2 parameters are not used.
fillList The Chooser sends this message when the user selects a device icon. The p1 parameter contains a handle to a List Manager list. Your device package should use the List Manager to fill this list with choices for the particular device. The objName and p2 parameters are not used.
getSel The Chooser sends this message to determine which entries should be selected. The p1 parameter contains a handle to a List Manager list. Your device package should respond by inspecting the list and setting the selected or unselected state of each entry, using the LSetSelect function. You should alter only the entries that require updating. The Chooser does not send this message for serial printers.
select If your device package does not allow multiple selections, the Chooser sends this message to your packages when the user selects a device from the device list. You should record the user’s selection, preferably in your Chooser extension file. Your device package may not call the List Manager in response to this message.
If your package accepts fillList messages, the objName parameter is undefined and the p2 parameter gives the row number of the selected device.
If your package does not accept fillList messages, the objName parameter contains a pointer to a string of up to 32 characters that contains the name of the device. If the device is an Appletalk device, the p2 parameter gives the AddrBlock value for the address of the selected AppleTalk device. (See the chapter “AppleTalk” for more information.)
deselect If your device package does not allow multiple selections, the Chooser sends this message to your packages when the user deselects a device in the device list. Your device package may not call the List Manager in response to this message.
If your package accepts fillList messages, the objName parameter is undefined and the p2 parameter gives the row number of the selected device.
If your package does not accept fillList messages, the objName parameter contains a pointer to a string (of up to 32 characters) containing the name of the device. If the device is an Appletalk device, the p2 parameter gives the AddrBlock value for the address of the selected AppleTalk device. (See the chapter “AppleTalk” for more information.)
terminate The Chooser sends this message when the user selects a different device icon, closes the Chooser window, or changes zones. Your device package should perform any necessary clean-up tasks, but should not dispose of the device list. The objName and p2 parameters are not used.
button The Chooser sends this message when the user clicks one of the buttons in the Chooser window. The low-order byte of the p2 parameter contains 1 if the user clicked the Left button, 2 if the user clicked the Right button, 3 if the user clicked the On radio button, and 4 if the user clicked the Off radio button. You must perform the appropriate highlighting for the radio buttons. The high-order word of this parameter contains the modifier bits from the mouse up event. See the chapters “The Control Manager” and “The Event Manager” for more information.
Allocating private storage
Device packages initially have no data space allocated. There are two ways your package can acquire data space:
n Use the List Manager to allocate extra memory in the device list.
n Create a resource.
The Chooser uses column 0 of the device list to store the names displayed in the list box; for device packages that do not accept fillList messages, it uses column 1 to store the 4-byte AppleTalk internet addresses of the devices in the list. Therefore, your device package can use column 1 and higher (if it accepts fillList messages) or column 2 and higher to store private data. You can use standard List Manager routines to add these columns, store data in them, and retrieve the data stored there. Your device package can also use the refCon field of the device list for its own purposes.
Using the device list is limited by the fact that the Chooser disposes of the device list whenever the user changes device types or changes the current zone. However, the Chooser does call your device package with the terminate message before it disposes of the list.
Also, if your device package does not accept fillList messages, the Chooser disposes of the device list whenever a new response from the AppleTalk zone interrogation arrives. However, the Chooser does call the getSel message immediately afterwards.
The second way to get storage space is to create a resource in the device resource file. This file is always the current resource file when the Chooser sends a message to the package, so you can use the GetResource routine to obtain a handle to the storage.
It is important for most device packages to record which devices the user has chosen. To do this, the recommended method is to create a resource in your driver resource file. This resource can be of any type; in fact, it’s advantageous to provide your own resource type so that no other program will try to modify it. If you choose to use a standard resource type, you should use only resource IDs in the range –4080 through –4065.
Writing a Desk Accessory
Desk accessories are device drivers that act like small applications. Desk accessories typically provide a user interface with a window and a menu, perform some limited function, and are opened from the Apple menu. The Chooser is an example of a desk accessory.
Desk accessories were originally designed for the Macintosh environment because they offered two distinct advantages over applications. They offered both a limited degree of multitasking and a primitive form of interprocess communication. However, applications under the system software version 7.0 environment enjoy far more sophisticated versions of these capabilities. Users can even open applications from the Apple menu. For these reasons, you would be better served by writing a small application than by writing a desk accessory.
If you’re certain you need to write a desk accessory, you should read this section. You might want to read the chapters about the Event Manager, the Window Manager, the Dialog Manager, and the Menu Manager in the Inside Macintosh: Macintosh Toolbox volume as well.
How Desk Accessories Work
In system software version 7.0 environment, when the user opens a desk accessory (or when an application calls the Menu Manager routine OpenDeskAcc) the system switches out the current application, loads the desk accessory into the system heap, and calls the desk accessory’s Open driver subroutine. The desk accessory can respond by creating its window and menu.
When events occur, the Event Manager directs them to the desk accessory by calling its Control driver subroutine. The Event Manager handles switching between applications and the desk accessories in the system heap and passing along the events meant for the desk accessory. The desk accessory need only respond to the Control request.
When the user closes the desk accessory (by closing its window or choosing Quit from its menu) or an application closes the desk accessory (by calling the Menu Manager routine CloseDeskAcc), the desk accessory disposes of its window (if any) and any other data structures associated with it.
In a single-application environment in system software version 6.0 or in multiple-application environment where the desk accessory is opened in the application’s partition (for example, when the user holds the Option key while opening the desk accessory from the Apple menu), the Event Manager handles events for desk accessories in a slightly different manner, although it still translates them into Control requests. See the chapter “The Event Manager” in the Inside Macintosh: Macintosh Toolbox volume for details.
Creating a Driver Resource for a Desk Accessory
To create a desk accessory, you must create it as a driver resource and include it in a resource file, as described in “Creating a Driver Resource” on page 2-5. Typically, you store your desk accessory driver resource in a desk accessory file, which allows you to include a 'BNDL' resource to give your desk accessory an icon, and the user stores your desk accessory file in the Apple Menu Items folder.
In addition to the driver header fields important for all drivers, described in “Creating a Driver Resource,” three fields are of particular importance to desk accessories:
n The drvrEMask field. This field contains an event masks specifying which events your desk accessory can handle. If your desk accessory has a window, you should include keyboard, activate, update, and mouse-down events, but you should not include mouse-up events. When an event occurs, the Event Manager checks this field to determine whether the desk accessory can handle the type of event, and if so, calls the desk accessory’s Control subroutine. See the chapter “The Event Manager” in the Inside Macintosh: Macintosh Toolbox for more information about events and event masks.
n The drvrMenu field. This field contains the menu ID of your desk accessory’s menu, if it has one, or any one of its menus, if it has more than one. Otherwise, it contains 0. The menu ID for a desk accessory’s menu must be negative and must be distinct from the menu ID for other desk accessories.
n The drvrDelay field and the dNeedTime flag of the drvrFlags field. Desk accessories often need to perform predefined actions periodically. For example, a clock desk accessory may want to change the time it displays every second. If your desk accessory needs to perform a periodic action, set the dNeedTime flag and use the drvrDelay field to indicate how often the action should occur. The section “Creating a Driver Resource” describes these fields in more detail.
Of the five possible driver subroutines, your desk accessory needs to implement three: Open, Close, and Control. You can implement a Prime and Status subroutine if needed.
Opening and Closing a Desk Accessory
In your desk accessory’s Open subroutine, you should:
n Create the desk accessory’s window. You can do this with the Dialog Manager function GetNewDialog or NewDialog. You should specify that the window be invisible because the OpenDeskAcc routine will display it. You should set the windowKind field of the window’s windowRecord data structure to the desk accessory’s driver reference number, which you can find in the device control entry. You should also store a copy of the window pointer in the dCtlWindow field of the device control entry.
n Allocate private storage as you would for any device driver.
n Create a menu or menus if needed for your desk accessory. You are responsible for adding your menu to the menu bar. See the chapter “The Menu Manager” in the Inside Macintosh: Macintosh Toolbox volume for more details.
If your Open subroutine is unable to complete its tasks (by running out of memory, for example), you should open only the minimum data structures possible, modify the code so it doesn’t respond to events, and display an alert indicating failure.
As for all drivers, your Close subroutine should undo the actions taken by the Open subroutine, disposing of the window and private storage, clearing the window pointer in the device control entry, and removing the menu from the menu bar.
Responding to Events
When the Event Manager determines an event has occurred that your desk accessory should handle, it checks the drvrEMask field of the driver header and, if that field indicates your driver handles the event type, it passes the event to your driver by means of your Control subroutine.
The Event Manager passes one of nine values in the csCode field to indicate the action to take:
Constant name Value Meaning
accEvent 64 Handle a given event
accRun 65 Time for periodic action
accCursor 66 Change cursor shape if appropriate
accMenu 67 Handle a given menu item
accUndo 68 Handle the Undo command
accCut 70 Handle the Cut command
accCopy 71 Handle the Copy command
accPaste 72 Handle the Paste command
accClear 73 Handle the Clear command
Along with the accEvent message, the Event Manager sends a pointer to an event record in the csParam field. You can respond to the event in whatever way is appropriate. For example, when your desk accessory becomes active you might install its menu in the menu bar.
If your desk accessory’s window is a modeless dialog box and you are calling the Dialog Manager routine IsDialogEvent in response to the event, you should set the windowKind field of your window record to 2 before you call the IsDialogEvent routine. Setting this field to 2 allows the Dialog Manager to recognize and handle the event properly. You should restore the original value of the windowKind field before returning from your Control subroutine.
The accCursor message makes it possible to change the shape of the cursor when its inside your desk accessory window and your desk accessory window is active. Your control routine should check whether the mouse location is in your window; if it is, you should set the cursor to the whatever cursor you desire by calling the QuickDraw routine InitCursor.
If your desk accessory window is a dialog box, you should respond to the accCursor message by generating a null event (storing the event code for a null event in an event record) and passing it to the Dialog Manager routine DialogSelect. This enables the Dialog Manager to blink the caret in editText items.
When the Event Manager sends the accMenu message, it provides the menu ID followed by the menu item number in the csParam field. You should take the appropriate action and then call the Menu Manager routine HiliteMenu with a value of 0 for the menuID parameter to remove the highlighting from the menu bar.
You should respond to the last five messages—accUndo through accClear—by processing the corresponding editing command in the desk accessory window, if appropriate. The chapter “The Scrap Manager” contains information about cutting and pasting.
Your desk accessory routines should restore the current resource file and the current grafPort if it changes either one.
Reference
This section describes the Device Manager routines, including the routines that allow your application to communicate with existing device drivers and the routines that provide support for your own device driver. This sections ends with a description of the 'DRVR' resource type.
Data Structures
The device control entry
TYPE DCtlEntry =
RECORD
dCtlDriver: Ptr; {pointer or handle to driver }
dCtlFlags: Integer; {flags }
dCtlQHdr: QHdr; {driver request queue header }
dCtlPosition: LongInt; {byte position}
dCtlStorage: Handle; {handle private storage}
dCtlRefNum: Integer; {driver reference number }
dCtlCurTicks: LongInt; {used internally }
dCtlWindow: WindowPtr; {pointer to desk accessory window }
dCtlDelay: Integer; {ticks between periodic actions }
dCtlEMask: Integer; {event mask for desk accessories }
dCtlMenu: Integer; {menu ID for desk accessories }
END;
dCtlDriver Contains a pointer or a handle to the driver, as determined by bit 6 of the dCtlFlags field.
dCtlFlags Contains flags about the abilities and state of the driver. The low-order byte contains these flags:
Bit Meaning
5 Set if driver is open.
6 Set if driver is RAM-based, that is, if
the dCtlDriver field contains a handle.
7 Set if driver is currently executing.
The high-order byte contains flags copied from the drvrFlags word of the driver resource. See “Creating a Driver Resource” on page 2-5 for more information.
dCtlQHdr Contains the header of the driver request queue, which is a standard Operating System queue. See the chapter “Operating System Utilities” in the Inside Macintosh: Operating System volume for more information about the QHdr data type.
dCtlPostion Indicates the current source or destination position for reading or writing. This field is only used by drivers of block devices. The value in this field is the number of bytes beyond the physical beginning of the medium used by the device. For example, immediately after the Disk Driver reads the first block of data from a 3.5-inch disk, this field contains the value 512.
dCtlStorage Contains a handle to a driver’s private storage. A driver may allocate a relocatable block of memory and keep a handle to it in this field.
dCtlRefNum Contains the driver reference number.
dCtlCurTicks Used internally.
dCtlWindow Contains a pointer to the desk accessory window. See “Reference” on page 2-34 for more information.
dCtlDelay Indicates the number of ticks to wait between periodic actions.
dCtlEMask Contains the desk accessory event mask. See “Reference” on page 2-34 for more information.
dCtlMenu Contains the menu ID of a desk accessory’s menu, if any. See “Reference” on page 2-34 for more information.
The Extended Device Control Entry
The device control entry for drivers that serve slot devices needs to store some additional information: the slot number, the slot resource ID, the device base address, and the external device ID. The extended device control entry, defined by the AuxDCE data type in “The extended device control entry” on page 2-35, contains additional fields to store these values.
The extended device control entry
TYPE AuxDCE=
RECORD
dCtlDriver: Ptr; {pointer or handle to driver }
dCtlFlags: Integer; {flags }
dCtlQHdr: QHdr; {driver request queue header }
dCtlPosition: LongInt; {byte position}
dCtlStorage: Handle; {handle private storage}
dCtlRefNum: Integer; {driver reference number }
dCtlCurTicks: LongInt; {used internally }
dCtlWindow: WindowPtr; {pointer to desk accessory window }
dCtlDelay: Integer; {ticks between periodic actions }
dCtlEMask: Integer; {event mask for desk accessories }
dCtlMenu: Integer; {menu ID for desk accessories }
dCtlSlot: Integer; {slot }
dCtlSlotId Integer; {slot ID }
dCtlDevVBase: Integer; {base address of card for driver }
reserved: Integer; {reserved; should be 0 }
dCtlExtDev: Integer; {external device ID }
fillByte: Integer; {reserved }
END;
The first eleven fields of the extended device control entry are identical to the fields of the device control entry, described in the previous section.
dCtlSlot Contains the slot number.
dCtlSlotId Contains the RsrcDirID for the slot resource.
dCtlDevBase Points to the device base address.
dCtlExtDev Contains the external device ID.
The chapter “The Slot Manager” in this book contains detailed information about these values.
Routines
The Device Manager provides a number of routines that provide low-level support for your own driver subroutines.
The GetDCtlEntry function allows your driver to obtain a handle to its device control entry.
The IODone routine allows your driver to notify the Device Manager that a request is complete. The Fetch and Stash routines allow your driver move characters into and out of data buffers. You pass a pointer to the device control entry in the A1 register to each of these three routines. The Device Manager uses the device control entry to locate the active request. If no such request exists, these routines generates system error dsIOCoreErr.
In the interest of speed, you invoke the Fetch, Stash, and IODone routines with jump vectors, stored in the global variables JFetch, JStash, and JIODone, rather than macros. You use a jump vector by moving its address onto the stack. An example is:
MOVE.L JIODone,-(SP)
RTS
The Fetch and Stash routines do not return a result code; if an error occurs, the System Error Handler is invoked.
2GetDCtlEntry
You can use the GetDCtlEntry function to obtain a handle to the device control entry of a device driver.
FUNCTION GetDCtrlEntry (refNum: Integer) : DCtlHandle;
refNum Contains the reference number of the driver.
DESCRIPTION
The GetDCtlEntry function returns a handle to the device control entry of the device driver indicated by the refNum parameter.
2Fetch
You can use the Fetch routine to get the next character from the data buffer.
DESCRIPTION
The Fetch routine gets the next character from the data buffer pointed to by the ioBuffer field of the parameter block of the pending request. It increments the ioActCount field by 1. If the ioActCount field equals the ioReqCount field, this function sets bit 15 of register D0. After receiving the last byte request, the driver should call the IODone routine.
Registers on entry
A1 pointer to the device control entry
Registers on exit
D0 character fetched; bit 15 = 1 if it’s the last character in the buffer
Jump vector
JFetch
2 Stash
You can use the Stash routine to store the next character from the data buffer.
DESCRIPTION
The Stash routine places the character in register D0 into the data buffer pointed to by the ioBuffer field of the parameter block of the pending request and increments the ioActCount field by 1. If the ioActCount field equals the ioReqCount field, this function sets bit 15 of register D0. After stashing the last byte requested, the driver should call the IODone routine.
ASSEMBLY-LANGUAGE INFORMATION
Registers on entry
A1 pointer to DCE
D0 character to stash
Registers on exit
D0 bit 15 = 1 if it’s the last character in the buffer
Jump vector
JStash
2IODone
You can use the IODone routine to notify the Device Manager that the current request has been satisfied.
DESCRIPTION
The IODone routine removes the current request from the driver request queue, marks the driver inactive, unlocks the driver and its device control entry (if allowed by the dNeedLock bit of the dCtlFlags word), and executes the completion routine if any. Then the Device Manager begins the next request in the driver request queue.
The section “Responding to the Device Manager” on page 2-9 explains in detail when to use this routine.
ASSEMBLY-LANGUAGE INFORMATION
Registers on entry
A1 pointer to DCE
D0 result code
Jump vector
JIODone
SEE ALSO
For an example of the IODone routine, see “Responding to the Device Manager” on page 2-9.
Resources
This section describes the driver resource, which you should use to store your device drivers and desk accessories. Listing 2-12 shows the Rez format of the 'DRVR' resource type. The driver resource has type 'DRVR'.
'DRVR' resource format
type 'DRVR' {
boolean = 0;
boolean dontNeedLock, needLock; /* lock drvr in memory */
boolean dontNeedTime, needTime; /* for periodic action */
boolean dontNeedGoodbye, needGoodbye; /* call before heap reinit */
boolean noStatusEnable, statusEnable; /* responds to Status */
boolean noCtlEnable, ctlEnable; /* responds to Control */
boolean noWriteEnable, writeEnable; /* responds to Write */
boolean noReadEnable, readEnable; /* responds to Read */
byte = 0;
integer; /* driver delay */
unsigned hex integer; /* DA event mask */
integer; /* DA menu */
unsigned hex integer; /* offset to Open */
unsigned hex integer; /* offset to Prime */
unsigned hex integer; /* offset to Control*/
unsigned hex integer; /* offset to Status */
unsigned hex integer; /* offset to Close */
pstring; /* driver name */
hex string; /* driver code */
};
The driver resource begins with seven flags that specify certain characteristics of the driver.
You need to set the dNeedLock flag if your driver’s code should be locked in memory.
You set the dNeedTime flag of the drvrFlags word if your device driver needs to perform some action periodically.
You need to set the dNeedGoodbye flag if you want your application to receive a goodBye Control request before the heap is reinitialized.
The last four flags indicate which Device Manager requests the driver’s routines can respond to.
The next element of the resource specifies the time between periodic tasks.
The next two elements provide an event mask and menu ID for desk accessories. The section “Writing a Desk Accessory” on page 2-31 describes these fields.
Offsets to the driver routines follow the desk accessory fields. See the section “Entering and Exiting From Driver Subroutines” on page 2-9 for more information about the subroutine offsets.
The next element of the driver resource is the driver name. You can use uppercase and lowercase letters when naming your driver, but the first character should be a period—.YourDriver, for example.
Your driver routines, which follow the driver name, must be aligned on a word boundary.
The section “Creating a Driver Resource” on page 2-5 discusses this structure in detail.
Summary
This section lists the declarations and definitions from this chapter. You might want to supplement this information with the information in the summary section of the chapter “The Device Manager,” in this book.
Constants
{Chooser messages}
CONST initMsg = 11; {the user selected this device package}
newSelMsg = 12; {the user made new device selections}
fillListMsg = 13; {fill the device list with choices}
getSelMsg = 14; {mark one or more choices as selected}
selectMsg = 15; {the user made a selection}
deselectMsg = 16; {the user cancelled a selection}
terminateMsg = 17; {allows device package to clean up}
buttonMsg = 18; {the user selected a button}
Data Types
TYPE DCtlEntry =
RECORD
dCtlDriver: Ptr; { pointer or handle to driver }
dCtlFlags: Integer; { flags }
dCtlQHdr: QHdr; { driver request queue header }
dCtlPosition: LongInt; { byte position used by I/O operations }
dCtlStorage: Handle; { handle to driver’s private storage }
dCtlRefNum: Integer; { driver reference number }
dCtlCurTicks: LongInt; { used internally }
dCtlWindow: WindowPtr; { pointer top driver’s window }
dCtlDelay: Integer; { ticks between periodic actions }
dCtlMenu: Integer; {menu ID (for desk accessories) }
dCtlSlot: Integer; {slot }
dCtlSlotId Integer; {slot ID }
dCtlDevVBase: Integer; {base address of card for driver }
reserved: Integer; {reserved; should be 0 }
dCtlExtDev: Integer; {external device ID }
fillByte: Integer; {reserved }
END;
AuxDCEPtr = ^AuxDCE;
AuxDCEHandle = ^AuxDCEPtr;
Routines
Driver Support Routines
FUNCTION GetDCtrlEntry (refNum: Integer) : DCtlHandle;
Assembly-Language Information
Routines Requiring Jump Vectors
Routine Jump Vector
Fetch JFetch
Stash JStash
IODone JIODone
The Slot Manager
Introduction to Slots and Cards3-3
Address allocations3-5
Firmware3-7
The format block3-7
The sResource directory3-8
sResource Data Structures3-8
sResource Types and sResource Names3-10
The Board sResource3-11
About the Slot Manager3-12
Using the Slot Manager3-14
Enabling and Disabling NuBus Cards3-14
Deleting and Restoring sResource Data Structures3-15
Enabling and Disabling sResource Data Structures3-15
Searching for sResource Data Structures3-16
Getting Information from sResource Data Structures3-18
Reference to the Slot Manager3-20
Data Structures3-20
Determining the Version of the Slot Manager3-22
Finding sResource Data Structures3-24
Enabling, Disabling, Deleting, and Restoring sResource
Data Structures3-35
Getting Information from sResource Data Structures3-40
Loading Drivers and Executing Code from sResource
Data Structures3-53
Traversing Firmware of Expansion Cards3-57
Getting Information about Expansion Cards and
Declaration ROMs3-58
Getting Access to Expansion Cards’ Parameter RAM3-65
Summary of the Slot Manager3-69
3The Slot Manager
This chapter describes how your application or device driver can use the Slot Manager to identify expansion cards and communicate with the firmware on each card.
You need to use the Slot Manager only if you are writing an application or a device driver that must address an expansion card directly. For example, you need to use the Slot Manager if you are writing a driver for a video card, but not if you only want to display information on a monitor for which a device driver already exists.
The Slot Manager provides routines to help you search through the data structures that expansion cards use to organize the information in their firmware. The meaning of the information in the data structures varies from card to card; you need to know the specifics of a card in order to interpret its data structures.
This chapter provides a brief introduction to Apple’s implementation of NuBus and expansion cards. This introduction explains the firmware data structures, but does not give much detail about the information these data structures contain. To interpret these data structures, you need to know the information in Designing Cards and Drivers for the Macintosh Family, as well as information specific to the card you’re examining.
If you are designing an expansion card, you must read Designing Cards and Drivers for the Macintosh Family. If you are writing a driver for a device on a card, you should also read the chapters “The Device Manager” and “Writing Your Own Device Driver” in this book.
After the introduction to the NuBus and expansion card design, this chapter discusses how you can
n determine the version of the Slot Manager that is available
n find information in the firmware of an expansion card
n enable and disable data structures in expansion card firmware
n load drivers and execute code from expansion card firmware
n check the status of expansion cards
n read and change the slot parameter RAM
Introduction to Slots and Cards
The Macintosh family of computers supports a processor-direct slot (PDS) expansion interface and a NuBus expansion interface.
The processor-direct slot, or PDS, is connected to the processor bus, which gives it direct access to the microprocessor and therefore a speed advantage over the NuBus. However, since the PDS expansion interface is an extension of the microprocessor, the configuration of the slot connector depends on which processor is used by the computer. For information specific to PDS expansion cards, see Designing Cards and Drivers for the Macintosh Family.
The Macintosh II-family computers include the NuBus expansion interface with configurations ranging from one to six identical slot connectors. The Macintosh system uses a slot ID in the range $09 to $0E to identify NuBus slots.
For convenience, this section refers to a NuBus configuration with six slots represented by slot IDs $09 through $0E. Keep in mind that some Macintosh family computers use only some of these slot IDs. For example, the Macintosh IIcx uses only slot IDs $09 through $0B. See Guide to the Macintosh Family Hardware for more information. <36pt\>\x12 <8bat\>u
In the Macintosh II-family of computers, the processor bus (which connects the CPU to RAM, ROM, the FPU) and the NuBus (which connects the NuBus expansion slots) are connected by a processor-bus to NuBus interface, or bus interface, as shown in Figure 3-1.
Simplified processor-bus and NuBus architecture
Both the processor bus and the NuBus are 4 bytes wide. The bus interface transfers bytes between the buses in byte lanes. Because the processor bus and the NuBus interpret the significance of bytes within words differently, the bus interface must perform byte lane swapping between the two buses.
The bus interface also performs some address translation between the two buses. It maps certain address ranges on each bus are to different address ranges on the other bus.
Designing Cards and Drivers for the Macintosh Family discusses byte lanes and address translation in more detail.
The next section, “Address allocations,” discusses the address ranges assigned by the Macintosh architecture to each NuBus slot.
The section “Firmware,” on page 3-7 introduces the data structures card’s use to organize information in their firmware.
Address allocations
The Macintosh architecture assigns certain address ranges to each NuBus slot. The processor communicates with an expansion card by reading and writing to memory in the address range of the card. The expansion cards can also communicate with each other in this manner.
The NuBus architecture allows full 32-bit addresses, providing four gigabytes of address space. Suitably equipped Macintosh computers with system software version 7.0 also support full 32-bit addressing, while earlier versions of the system software use 24-bit addressing. This section describes address space allocation in both the 24-bit and 32-bit modes.
In 32-bit mode, the Macintosh architecture assigns two address ranges to each NuBus slot: a 256-megabyte super slot space and a 16-megabyte standard slot space.
The four gigabytes of the 32-bit address space contain 16 regions of 256 megabytes apiece, each of which constitutes the super slot space for one possible slot ID. Each super slot space spans an address range $s000 0000 through $sFFF FFFF, where s is a hexadecimal digit $0 through $F.
For example, the address ranges $9000 0000 – $9FFF FFFF constitute the super slot space for slot ID $09. Since the Macintosh II family uses only slot IDs $09 through $0E, only six super slot spaces, $9xxx xxxx through $Exxx xxxx, are actually used.
The standard slot spaces are 16 megabytes apiece and have addresses of the form $Fsxx xxxx (that is, $Fs00 0000 – $FsFF FFFF) where s is the slot ID. As with super slot spaces, the Macintosh uses only standard slot spaces corresponding to slot IDs $9 through $E (that is $F9xx xxxx through $FExx xxxx).
Figure 3-2 shows the super slot and standard slot subdivisions of the 32-bit addressing region.
NuBus address space
In Figure 3-2, the super slot space and the standard slot space for slot ID $09 are shaded.
In 24-bit mode, the Macintosh system can only address a fraction of each card’s allocated address range. In this mode, the system assigns each slot a one megabyte minor slot space. The bus interface translates 24-bit address on the processor bus with the form $sx xxxx (where s is a slot ID) into 32-bit NuBus addresses of the form $Fs0x xxxx, which is the first megabyte of the slot’s standard slot space.
For example, 24-bit addresses in the range $90 0000 through $9F FFFF constitute the minor slot space corresponding to slot ID $09. The hardware translates these addresses into the NuBus address range $F900 0000 through $F90F FFFF.
Table 3-1 shows the address allocations for each slot ID.
Slot allocations by slot ID
Slot 24-bit minor 32-bit minor Standard Super
ID slot space slot space slot space slot space
$9 $9x xxxx $F90x xxxx $F9xx xxxx $9xxx xxxx
$A $Ax xxxx $FA0x xxxx $FAxx xxxx $Axxx xxxx
$B $Bx xxxx $FB0x xxxx $FBxx xxxx $Bxxx xxxx
$C $Cx xxxx $FC0x xxxx $FCxx xxxx $Cxxx xxxx
$D $Dx xxxx $FD0x xxxx $FDxx xxxx $Dxxx xxxx
$E $Ex xxxx $FE0x xxxx $FExx xxxx $Exxx xxxx
Firmware
The firmware of a NuBus expansion card contains information that identifies the card and its functions, and allows the card to communicate with the Slot Manager. It may also include other information, such as initialization code or code for drivers that communicate with devices on the card. The sole purpose of many Slot Manager routines is to provide access to this firmware information.
This section discusses the structure of the information in firmware. You’ll need to understand the structure of this information in order to use the Slot Manager routines. If you plan to design firmware, you will want to supplement the information in this section with the information in Designing Cards and Drivers for the Macintosh Family.
The physical location of an expansion card’s firmware is called its declaration ROM. The firmware in a card’s declaration ROM includes these elements:
n The format block. The format block allows the Slot Manager to find the declaration ROM and to validate it. It contains some identification information and an offset to the sResource directory.
n The sResource directory. The sResource directory is a list that contains offsets to all of the sResource data structures in the card’s firmware.
n The sResource data structures. A typical sResource data structure contains information about a single function or capability of the expansion card, although some sResource data structures may contain other data—for example, device drivers, icons, fonts, code, or vendor-specific information.
Every card must have a single Board sResource data structure, which contains information about the card as a whole. An sResource data structure relating to a specific function is called a functional sResource, and a card may have as many of them as necessary.
The next few sections discusses these data structures in more detail.
The format block
The format block always resides at the highest address in the standard slot space of a declaration ROM. It contains information about the declaration ROM and an offset to the sResource directory. The Slot Manager uses the format block to validate the declaration ROM and locate the sResource data structures.
The format block also contains a value that specifies which of the four byte lanes the declaration ROM uses, called the valid byte lanes. Some declaration ROMs do not use all four byte lanes and therefore the system cannot address every memory location in their address space.
Designing Cards and Drivers for the Macintosh Family defines the structure of the format block and gives examples of how the valid byte lanes affect communication with a declaration ROM.
The sResource directory
The sResource directory lists all the sResource data structures in the card firmware and provides an offset to each one.
Figure 3-3 shows the format of the sResource directory.
The sResource directory structure
Each element of the sResource directory contains an 8-bit sResource ID followed by a 24-bit offset. The sResource ID identifies the sResource data structure. Each sResource data structure in the card firmware has a unique ID. Apple reserves ID numbers in the range $00 – $EF for sResource data structures defined for all declaration ROMs; at present there is only one of these: sResource ID $01, which indicates a Board sResource. The sResource ID numbers appear in the sResource directory in ascending order.
The sResource ID $FF indicates an end-of-list marker.
The offset field of each entry contains an offset (counting only bytes accessible by valid byte lanes) to the sResource data structure. The final offset field must have a value of 0.
sResource Data Structures
Every sResource data structure contains of an sResource list. Each entry of an sResource list contains information about the sResource or contains a signed offset to another data structure, which might contain icons, code, device drivers, or other information relating to the sResource.
The sResource data structure is made up of its sResource list and all the information pointed to by the sResource list entries.
An sResource data structure is sometimes referred to as a slot resource. Note, however, that a slot resource is a data structure in the firmware of a NuBus card and not a type of Macintosh resource. <36pt\>\x12 <8bat\>u
The sResource list structure is similar to the sResource directory structure. Each sResource list entry has an 8-bit ID field, which identifies the type of the entry, and a 24-bit offset field, which can contain a byte of data, a word of data, or an offset to a larger block of data. The final entry in an sResource must contain the value $FF in the type field and the value 0 in the data field.
Figure 3-3 shows the format of an sResource list.
sResource list structure
The ID field of each entry indicates the type of information in the offset field of the entry. Apple reserves the range $00 – $7E for common sResource entry types. Designing Cards and Drivers for the Macintosh Family gives a complete list of the Apple-defined sResource list IDs and their meanings.
The offset field of each entry in an sResource list can contain data or it can contain an offset to a block of data. This field takes one of three possible forms:
n It may contain two $00 bytes followed by an 8-bit byte of data.
n It may contain a $00 byte followed by a 16-bit word of data.
n It may contain a 24-bit offset to larger data structures
Table 3-2 lists the larger data structures commonly used in sResource data structures.
Larger Data Types
Data Type Description
Long 32 bits, signed or unsigned.
Pointer 32 bits, signed or unsigned.
cString One-dimensional array of bytes, ending with $00.
sBlock A sized block of data. See Figure 3-5.
SExecBlock A sized block of code. See Figure 3-5.
The sBlock and SExecBlock data structures begin with a size field, which contains the physical size of the block (including the size field). The sBlock structure follows the size field with its actual data. The SExecBlock field follows the size field with some additional fields and code.
Format of the sBlock and SExecBlock data structures
sResource Types and sResource Names
The Slot Manager requires that each sResource list contain an sRsrcType entry, which identifies the sResource type, and an sRsrcName entry, which provides the sResource name.
The sRsrcType entry contains an offset to an sRsrcType record—a record containing 2 long words that identifies the sResource type.
Figure 3-6 shows the format of an sRrscType record.
The sRsrcType record format
Category The most general classification of card functions. Some example categories are CatDisplay and CatNetwork.
cType The subclass of the category. Within the CatDisplay category, for example, there is a TypVideo subcategory; within the CatNetwork category, there is a TypAppleTalk subcategory.
DrSW The driver software interface of the subcategory. For example, under the category Display and the subcategory Video, there is a DrSWApple software interface, which indicates the Apple-defined interface to work with QuickDraw using Macintosh Operating System frame buffers.
DrHW The identification of the specific hardware device associated with the driver software interface.
The value of each sRsrcType entry is unique and assigned by Apple Developer Technical support.
The sRsrcName entry contains an offset to a cString data structure containing the sResource name. By convention, the sRsrcName field is derived by stripping the prefixes from the sRsrcType values and separating the fields by underscores. For example, the sRsrcName for an sResource whose sRsrcType values are CatDisplay, TypVideo, DrSWApple, and DrHWTFB becomes 'Display_Video_Apple_TFB'.
Designing Cards and Drivers for the Macintosh Family provides information about these and other entry types.
The Board sResource
The Board sResource is a special sResource data structure that must be present in the firmware of every card that communicates with the Slot Manager. By convention, it has sResource ID $01 and it appears first in the sResource directory.
The entries in the Board sResource list provide the Slot Manager with a card’s identification number, vendor information, board flags, and initialization code. Like all sResource data structures, the Board sResource list must include an sRsrcType entry and an sRsrcName entry. The Board sRsrcType entry must contain the constants CatBoard ($0001), TypBoard ($0000), DrSWBoard ($0000), and DrHWBoard ($0000). The Board sResource name does not follow the same convention as other sResource names—the Board sResource name is the name of the entire card, for example 'Mac II Monochrome Video Card'.
The Board sResource list must also contain a BoardId entry, a word that contains the card design identification number assigned by Apple Macintosh Developer Technical Support. Other Apple-defined entries specifically for Board sResource data structures are discussed in Designing Cards and Drivers for the Macintosh Family.
Figure 3-7 shows a sample Board sResource. It shows an sRsrcType and sRsrcName entry and also includes three entry types, BoardID, PRAMInitData, and PrimaryInit, that are discussed in Designing Cards and Drivers for the Macintosh Family.
Sample Board sResource
About the Slot Manager
The Slot Manager provides three basic services:
n At system startup time, it examines each slot and initializes any expansion cards it finds.
n It maintains data structures that contain information about each slot and every available sResource data structure.
n It provides functions that allow you to get information about expansion cards and their sResource data structures.
There are two variations of the system software version 7.0 Slot Manager: version 1 and version 2. Version 1 of Slot Manager is supplied with the version 7.0 System file on disk for use with Macintosh II-family computers designed and built before the system software version 7.0 was available. Version 2 is included in the ROM of newer Macintosh II-family computers.
When the user starts up a Macintosh II-family computer, the version of the Slot Manager in ROM searches each slot for a declaration ROM and creates a slot information record for each slot. The section “Getting Information about Expansion Cards and Declaration ROMs” reference section, later in this chapter, shows the definition of the SInfoRecord data type.
The ROM of early Macintosh II-family computers may contain early versions of the Slot Manager that address NuBus cards in 24-bit mode and may not be able to identify some cards. After version 1 of the Slot Manager is loaded, it locates these cards. <36pt\>\x12 <8bat\>u
As the Slot Manager searches the slots, it identifies all of the sResource data structures in each declaration ROM and creates a table—the Slot Resource Table, or SRT—that lists all of the sResource data structures currently available to the system.
The Slot Manager then initializes the six parameter RAM bytes reserved for each slot. If the slot has an expansion card with a PRAMInitData entry in its Board sResource, the Slot Manager uses the values in that entry to initialize the parameter RAM; otherwise, it clears the parameter RAM bytes to 0.
After the parameter RAM initialization, the Slot Manager disables interrupts and executes the code in the PrimaryInit entry of each card’s Board sResource.
If certain values (defined by the Start Manager) are set in a card’s parameter RAM, a card with an sRsrcBootRec entry may take over the system startup process. The system gives control to the code in this entry early in the startup sequence, before the system patches are loaded.
Designing Cards and Drivers for the Macintosh Family describes the PRAMInitData, PrimaryInit, and sRsrcBootRec entry types.
If no card takes over, the normal system startup continues. After version 1 of the Slot Manager is loaded, it conducts a second search for declaration ROMs, this time in 32-bit mode. If it finds any new NuBus cards, it adds their sResource data structures to the Slot Resource Table and executes the code in their PrimaryInit entries. (Version 2 of the Slot Manager, which resides in ROM, does not need to conduct a second search.)
After all system patches have been installed, version 1 or later of the Slot Manager executes the code in any SecondaryInit entries it finds in the declaration ROMs. It does not reexecute the code from PrimaryInit entries, reinitialize parameter RAM, or restore any sResource data structures deleted by the PrimaryInit code.
Versions of the Slot Manager earlier than version 1 do not execute code from SecondaryInit entries. <36pt\>\x12 <8bat\>u
After the Slot Manager executes SecondaryInit code, it searches for sResource data structures that have an sRsrcFlags entry with the fOpenAtStart flag set. When the Slot Manager finds an sResource data structure with this flag set, it loads the device driver from the sRsrcDrvrDir entry of the sResource, or calls the code in sResource’s sRsrcLoadRec entry, which loads the sResource’s device driver.
Finally, the system executes initialization ('INIT') resources.
See Designing Cards and Drivers for the Macintosh Family for details about the sRsrcFlags, sRsrcDrvrDir, and sRsrcLoadRec entry types.
Using the Slot Manager
The majority of Slot Manager routines search for sResource data structures in the Slot Resource Table or provide information from these structures.
The Slot Manager provides a variety of methods to find an sResource data structure. These methods include searching for an sResource data structure with a particular sResource ID, searching for an sResource data structure with a particular sResource type, searching through all sResource data structures, searching through only the enabled sResource data structures, and so on.
The Slot Manager also provides a number of routines that return information from sResource list entries. Some of these routines, like the SReadByte and SGetCString functions, return one particular type of data structure. Some others, like the SFindStruct function, can return information about any data structure. Still other functions, the SGetDriver and SExec functions, not only return information from an sResource data structure but also preform functions like loading the sResource data structure’s driver or executing the code of an SExecBlock data structure.
In addition to searching for sResource data structures and getting information out of them, the Slot Manager allows you to enable and disable NuBus cards, manipulate the Slot Resource Table, get information from slot information records, get status information, and read and change expansion cards’ parameter RAM.
Enabling and Disabling NuBus Cards
Version 1 and later of the Slot Manager allows you to temporarily disable your NuBus card. You might want to do this, for example, if you are designing a NuBus card that must be addressed in 32-bit mode or that requires RAM-based system software patches to be loaded into memory before the card is initialized. Your PrimaryInit code can disable the card temporarily and the SecondaryInit code can reenable it.
To disable a NuBus card temporarily, the initialization routine in your PrimaryInit record should return in the seStatus field of the SEBlock data structure (described in “Loading Drivers and Executing Code from sResource Data Structures” on page 3-53) an error code with a value in the range svTempDisable ($8000) through svDisabled ($8080). The Slot Manager places this code in the siInitStatusV field of the slot information record that the Slot Manager maintains for the slot, and it places the fatal error smInitStatVErr (–355) in the initStatusA field of the sInfo record. The card and its sResource data structures are then unavailable for use by the Operating System.
After the Operating System loads RAM patches, the Slot Manager checks the value of the siInitStatusA field. If this value is greater than or equal to 0, indicating no error, the Slot Manager executes the SecondaryInit code. If the value in the siInitStatusA field is smInitStatErr, the Slot Manager checks the siInitStatusV field. If the value of the siInitStatusV field is in the range svTempDisable through svDisabled, the Slot Manager clears the siInitStatusA field and runs the SecondaryInit code.
For examples of PrimaryInit and SecondaryInit code, see Designing Cards and Drivers for the Macintosh Family.
Deleting and Restoring sResource Data Structures
Some NuBus cards have sResource data structures to support a variety of combinations of system configurations or modes. The Slot Manager loads all of the sResource data structures during system initialization, and then the card’s PrimaryInit code can delete from the Slot Resource Table any sResource data structures that are not appropriate for the system as configured. If the user changes the system configuration or selects a different mode of operation, you can reinstall a deleted sResource data structure. The SDeleteSRTRec function deletes sResource data structures; the InsertSRTRec function reinstalls them.
Because none of the Slot Manager functions can search for sResource data structures that have been deleted from the Slot Resource Table, you must keep a record of all sResource data structures that you have deleted so that you will have the appropriate parameter values when you want to reinstall one.
When you reinstall an sResource data structure, you can also update the dCtlDevBase field in the corresponding device driver’s device control entry. The dCtlDevBase field holds the address of the sResource data structure that is used by that device driver. For a video driver, for example, the dCtlDevBase field might contain the address of the frame buffer. Use the InsertSRTRec to update the dCtlDevBase field. See the Device Manager chapter of this volume for a definition of the device control entry.
Enabling and Disabling sResource Data Structures
Under certain circumstances, you might want to disable an sResource data structure while it remains listed in the Slot Resource Table. For example, a NuBus card might provide several modes of operation, only one of which can be active at a given time. Your application might want to disable the sResource data structures associated with all but the active mode, but still list all available modes in a menu. When the user selects a new mode, your application can then disable the currently active sResource data structure and enable the one the user selected.
You use the SetSRsrcState function to enable or disable an sResource data structure. Listing 3-1 disables the sResource data structure in slot $0A with an sResource ID of 128 and enables the sResource data structure in the same slot with an ID of 131.
Disabling and Enabling sResource data structures
VAR
mySpBlk: SpBlock;
myErr: OSErr;
BEGIN
{Set required values in parameter block.}
WITH mySpBlk DO
BEGIN
spParamData := 1; {disable}
spSlot := $0A; {slot number}
spID := 128; {sResource ID}
spExtDev := 0; {ID of external device}
END;
myErr := SetSRsrcState(@mySpBlk);
IF myErr <> noErr THEN DoError(myErr);
WITH mySpBlk DO
BEGIN
spParamData := 0; {enable}
spSlot := $0A; {slot number}
spID := 131; {sResource ID}
spExtDev := 0; {ID of external device}
END;
myErr := SetSRsrcState(@mySpBlk);
IF myErr <> noErr THEN DoError(myErr);
END;
Searching for sResource Data Structures
The Slot Manager provides several routines that search for sResource data structures in the Slot Resource Table. These routines all allow you to specify for which sResource data structures to search, but they each provide slightly different options.
The SFindSRsrcPtr and SGetSRsrcPtr functions are the simplest. The SFindSRsrcPtr function requires you to specify a slot number and an sResource ID and returns a pointer to the sResource data structure with the specified ID in the specified slot.
The SGetSRsrcPtr function allows you to specify that you want the function to return a pointer to the next sResource data structure—that is, the one with the next higher sResource ID. When searching for the next sResource data structure, the SGetSRsrcPtr function also allows you to search for both enabled and disabled sResource data structures, or enabled ones only.
The SNextSRsrc and SGetSRsrc functions are similar, although they return more information about the sResource data structure, such as the fields of its sRsrcType entry.
The SNextTypeSRsrc and SGetTypeSRsrc functions allow even more control. With these functions, you can search for the next sResource data structure with a particular sResource type.
Table 1-1 summarizes the Slot Manager search routines and the options available for each.
Slot Manager search routines
State of Which Type of
sResources it Slots it sResource it sResource it
Function searches for searches searches for searches for
SFindSRsrcPtr Enabled only Specified slot Specified Any type
sResource only
SNextSRsrc Enabled only Specified slot and Next sResource Any type
higher slots only
SGetSRsrcPtr*, Your choice of Your choice of one Your choice of Any type
SGetSRsrc* enabled only or slot only or specified
both enabled and specified slot and sResource or
disabled higher slots next sResource
SNextTypeSRsrc Enabled only Specified slot and Next sResource Specified type
higher slots only only
SGetTypeSRsrc* Your choice of Your choice of Next sResource Specified type
enabled only or one slot only or only only
both enabled and specified slot and
disabled higher slots
* Available only with system software version 7.0 Slot Manager
Listing 3-2 shows how to search all slots for both enabled and disabled sResource data structures with an sResource type category of catDisplay and an sResource type subcategory of typVideo.
Searching for sResource data structures
VAR
mySpBlk: SpBlock;
myErr: OSErr;
BEGIN
{Set required values in parameter block.}
WITH mySpBlk DO
BEGIN
spParamData := 1; {fAll flag 1: search all sResources}
{fOneSlot flag 0: search all slots}
spCategory := $catDisplay; {search for Category catDisplay}
spCategory := $typeVideo; {search for cType typeVideo}
spDrvrSW := 0; {this field not being matched}
spDrvrHW := 0; {this field not being matched}
spTBMask := 0; {match only Category and cType fields}
spSlot := 0; {start search from here}
spID := 0; {start search from here}
spExtDev := 0; {ID of the external device}
END;
myErr := 0;
WHILE myErr = noErr DO {loop to search sResources}
BEGIN
myErr := SGetTypeSRsrc(@mySpBlk);
MySRsrcProcessor(mySpBlk); {your routine to process results}
END;
IF myErr <> smNoMoresRsrcs THEN DoError(myErr);
END;
Getting Information from sResource Data Structures
If you are writing a driver for a card device, you will most likely want access to the information in an sResource data structure.
The Slot Manager provides many functions that return information from the entries of an sResource data structure. The SOffsetData, SReadByte, and SReadWord functions return information from the offset field of an sResource list entry. The SReadLong, SGetCString, and SGetBlock functions return copies of the standard data structures pointed to by the offset field of an sResource list entry. The SFindStruct and SReadStruct functions allow access to other data structures pointed to by sResource list entries.
Listing 3-3 shows an example of reading information from an sResource. This example examines the name of the card in slot $0A.
Searching for sResource data structures
VAR
mySpBlk: SpBlock;
myErr: OSErr;
BEGIN
{First get a pointer to the Board sResource for slot $0A.}
WITH mySpBlk DO
BEGIN
spSlot := $0A; {search in this slot}
spID := 1; {assume Board sResource has ID 1}
END;
myErr := SFindSRsrcPtr(@mySpBlk);
IF myErr <> noErr THEN DoError(myErr);
{The spsPointer field of mySpBlock now contains a pointer }
{ to the Board sResource list. The SGetCString function }
{ uses this field as one of two input fields.}
mySpBlk.spID := 2; {sRsrcName entry}
myErr := SGetCString(@mySpBlk);
IF myErr <> noErr THEN DoError(myErr);
{The spResult field now points to a copy of the cString}
MyProcessCardName(mySpBlk.spResult);
END;
Reference to the Slot Manager
This section describes the routines you use to get information about the Slot Manager, expansion cards, and sResource data structures. Most of the routines in this section find an sResource data structure given some information about it or read information from an entry in an sResource list. Some of the routines allow you to read and set information about expansion cards, such as their parameter RAM values, and others allow you to manipulate Slot Manager data structures, like the Slot Resource Table.
Data Structures
Every Slot Manager function requires a pointer to a parameter block as a parameter, and returns an OSErr result code. Each routine uses only a subset of the fields of the parameter block, which is defined in Listing 3-4. See the routine descriptions for a list of the fields used with each routine.
Slot Manager parameter block
TYPE SpBlockPtr = ^SpBlock;
SpBlock = PACKED RECORD
spResult: LongInt; {result}
spsPointer: Ptr; {structure pointer}
spSize: LongInt; {size of structure}
spOffsetData: LongInt; {offset or data}
spIOFileName: Ptr; {reserved for Slot Manager}
spsExecPBlk: LongInt; {pointer to SEBlock data structure}
spParamData: Ptr; {flags}
spMisc: LongInt; {reserved for Slot Manager}
spReserved: LongInt; {reserved for Slot Manager}
spIOReserved: INTEGER; {ioReserved field from SRT}
spRefNum: INTEGER; {driver reference number}
spCategory: INTEGER; {Category field of sResource type}
spCType: INTEGER; {cType field of sResource type}
spDrvrSW: INTEGER; {DrvrSW field of sResource type}
spDrvrHW: INTEGER; {DrvrHW field of sResource type}
spTBMask: SignedByte; {sResource type bit mask}
spSlot: SignedByte; {slot number}
spID: SignedByte; {sResource ID}
spExtDev: SignedByte; {external device ID}
spHwDev: SignedByte; {hardware device ID}
spByteLanes: SignedByte; {valid byte lanes}
spFlags: SignedByte; {flags used by Slot Manager}
spKey: SignedByte; {reserved for Slot Manager}
END;
spResult A general-purpose field used to contain the results returned by several different routines.
spsPointer A pointer to a data structure. The field can point to an sResource data structure, a data block, or a declaration ROM, depending on the routine being executed.
spSize The size of the data block.
spOffsetData The contents of the offset field of an sResource data structure entry. Some routines use this field for other offsets or data.
spIOFileName Reserved for use by the Slot Manager.
spsExecPBlk Pointer to an SEBlock data structure (an SExec parameter block).
spParamData On input, this long word contains flags that determine what sResource data structures the Slot Manager searches. Bit 0 (the fAll flag) indicates when set that disabled sResource data structures should be included. When set, bit 1 (the fOneslot flag) restricts the search to sResource data structures on a single card. Bit 2 (the fNext flag) indicates when set that the routine find the next sResource data structure. The rest of the fields must be cleared to 0.
On output, this field indicates whether the sResource data structure is enabled or disabled (if 0, the sResource data structure is enabled; if 1, it is disabled).
spMisc Reserved for use by the Slot Manager.
spReserved Reserved for future use.
spIOReserved The value of the ioReserved field from the sResource data structure’s entry in the Slot Resource Table.
spRefNum The driver reference number of the driver associated with an sResource data structure, if there is one.
spCategory The Category field of the sResource type.
spCType The cType field of the sResource type.
spDrvrSW The DrvrSW of the sResource type.
spDrvrHW The DrvrHW of the sResource type.
spTBMask A mask that determines which sRsrcType fields the Slot Manager examines when searching for sResource data structures.
spSlot The number of the slot with the NuBus card containing the requested, or returned, sResource data structure.
spID The sResource ID of the requested, or returned, sResource data structure.
spExtDev The external device identifier. This field allows you to distinguish between devices on a card.
spHwDev The hardware device identifier from the sRsrcHWDevID field of the sResource data structure.
spByteLanes The byte lanes used by a declaration ROM.
spFlags Flags typically used by the Slot Manager.
spKey Reserved for use by the Slot Manager.
Since each routine uses a subset of the parameter block fields, each routine reference section includes a list of pertinent fields and how they are used.
The arrows show whether you provide a value in the field, the routine returns a value in the field, or both. The <zapf\>5 symbol designates fields that may be affected by the execution of the routine. Any value you store in one of these fields may be lost. Also, the meaning of these fields upon completion of the routine is undefined; your application should not depend on these values.
Determining the Version of the Slot Manager
Unlike many of the system software managers, which provide you with version information through the Gestalt function, the Slot Manager provides its own function for determining version information.
3SVersion
You can use the SVersion function to determine which version of the Slot Manager is in use by the Operating System.
FUNCTION SVersion (spBlkPtr: SpBlockPtr) : OSErr;
spBlkPtr Pointer to a Slot Manager parameter block.
<symbol\>\xac spResult LongInt The Slot Manager version number.
<symbol\>\xac spsPointer Ptr A pointer to additional information.
DESCRIPTION
The SVersion function returns the version number of the Slot Manager in the spResult field. Version number 1 corresponds to the RAM-based Slot Manager and version number 2 corresponds to the ROM-based Slot Manager. Versions of the Slot Manager before system software version 7.0 do not recognize the SVersion function and return a nonfatal error smSelOOBErr. The spsPointer field is reserved for future use as a pointer to additional information.
SPECIAL CONSIDERATIONS
The SVersion function does not move memory; your application may call this function at interrupt time.
The SVersion function is available only with version 1 or later of the Slot Manager. You can use the error code smSelOOBErr to determine if an earlier version of the Slot Manager is in use by the Operating System.
ASSEMBLY-LANGUAGE INFORMATION
The trap macro for the SVersion function is _SlotManager ($A06E). The routine selector is $0008.
Trap macro Selector
_SlotManager $0008
You must setup register D0 with the routine selector and register A0 with the address of the Slot Manager parameter block. When _SlotManager returns, register D0 contains the result code.
Registers on entry
A0 address of the parameter block
D0 $0008
Registers on exit
D0 result code
RESULT CODES
noErr 0 No Error
smSelOOBErr –338 Selector out of bounds; function not
implemented
SEE ALSO
For more discussion on the different versions of the Slot Manager, see “About the Slot Manager” on page 3-12.
Finding sResource Data Structures
The routines in this section locate sResource data structures in the Slot Resource Table and return pointers to them and additional information about them. You can use some of the routines to step through the sResource data structures, and some of the routines allow you to find disabled as well as enabled sResource data structures.
3SFindSRsrcPtr
You can use the SFindSRsrcPtr function to find an sResource data structure given its slot number and sResource ID. This function ignores disabled sResource data structures.
FUNCTION SFindSRsrcPtr (spBlkPtr: SpBlockPtr) : OSErr;
spBlkPtr Pointer to a Slot Manager parameter block.
<symbol\>\xac spsPointer Ptr A pointer to the sResource data structure.
<symbol\>\xae spSlot SignedByte The slot number of the requested sResource.
<symbol\>\xae spId SignedByte The sResource ID of the requested sResource.
<zapf\>5 spResult LongInt
SPECIAL CONSIDERATIONS
The SFindSRsrcPtr function does not move memory; your application may call this function at interrupt time.
ASSEMBLY-LANGUAGE INFORMATION
The trap macro for the SFindSRsrcPtr function is _SlotManager ($A06E). The routine selector is $0030.
Trap macro Selector
_SlotManager $0030
You must setup register D0 with the routine selector and register A0 with the address of the Slot Manager parameter block. When _SlotManager returns, register D0 contains the result code.
Registers on entry
A0 address of the parameter block
D0 $0030
Registers on exit
D0 result code
RESULT CODES
noErr 0 No Error
smNoMoresRsrcs –344 Requested sResource data structure not found
SEE ALSO
For information about the sResource data structure, see the section “Firmware” on page 3-7.
3SGetSRsrcPtr
You can use the SGetSRsrcPtr function to find an sResource data structure given its slot number and sResource ID. This function allows you to search disabled sResource data structures and allows you to step through sResource data structures.
FUNCTION SGetSRsrcPtr (spBlkPtr: SpBlockPtr) : OSErr;
spBlkPtr Pointer to a Slot Manager parameter block.
<symbol\>\xac spsPointer Ptr A pointer to the sResource data structure.
<symbol\>\xae spParamData LongInt The fAll, fOneslot, fNext flags.
<symbol\>\xae spSlot SignedByte The slot number of the requested sResource.
<symbol\>\xae spID SignedByte The sResource ID of the requested sResource.
<symbol\>\xae spExtDev SignedByte The external device identifier.
DESCRIPTION
The SGetSRsrcPtr function allows you to find any sResource data structure from the Slot Resource Table, even disabled ones.
You specify an sResource data structure with the spSlot, spID, and spExtDev fields. You must also include flags in bits 0, 1, and 2 of the spParamData field as follows:
n Set the fAll flag (bit 0) to search both enabled and disabled sResource data structures. Clear this flag to search only enabled sResource data structures.
n Set the fOneslot flag (bit 1) to search only the specified slot. Clear this flag to search all slots.
n Set the fNext flag (bit 2) to return information about the sResource data structure with the next higher sResource ID than the specified sResource data structure (or the first one on the next card if the fAll flag is set). Clear this flag to return data about the specified sResource data structure.
The SGetSRsrcPtr function returns a pointer to the specified sResource data structure, or the one following it if you set the fNext flag.
The SGetSRsrcPtr function updates the values in the spSlot, spID, and spExtDev fields to correspond to the sResource data structure that it found. If you cleared the fNext flag, these fields retain the values you specified when calling the function.
SPECIAL CONSIDERATIONS
The SGetSRsrcPtr function does not move memory; your application may call this function at interrupt time.
This function is available with version 1 or later of the Slot Manager.
ASSEMBLY-LANGUAGE INFORMATION
The trap macro for the SGetSRsrcPtr function is _SlotManager ($A06E). The routine selector is $001D.
Trap macro Selector
_Slot Manager $001D
You must setup register D0 with the routine selector and register A0 with the address of the Slot Manager parameter block. When _SlotManager returns, register D0 contains the result code.
Registers on entry
A0 address of the parameter block
D0 $001D
Registers on exit
D0 result code
RESULT CODES
noErr 0 No Error
smNoMoresRsrcs –344 Requested sResource data structure not found
SEE ALSO
For more information about the sResource data structure, see the section “Firmware” on page 3-7.
3SRsrcInfo
You can use the SRsrcInfo function to find an sResource data structure given its slot number and sResource ID. This function also provides additional information about the sResource data structure.
FUNCTION SRsrcInfo (spBlkPtr: SpBlockPtr) : OSErr;
spBlkPtr Pointer to a Slot Manager parameter block.
<symbol\>\xac spsPointer Ptr A pointer to the sResource data structure.
<symbol\>\xac spIOReserved Integer Value of Slot Resource Table ioReserved field.
The SRsrcInfo function allows you to find an sResource data structure from the Slot Resource Table, and provides additional information such as the type of the sResource data structure.
You specify an sResource data structure with the spSlot, spID, and spExtDev fields.
The SRsrcInfo function returns a pointer to the sResource data structure in the spsPointer field and information about the sResource type in the spRefNum, spCType, spDrvrSW, spDrvrHW fields. The function returns other information about the sResource data structure in the spIOReserved, spRefNum, and spHwDev fields.
SPECIAL CONSIDERATIONS
The SRsrcInfo function does not move memory; your application may call this function at interrupt time.
ASSEMBLY-LANGUAGE INFORMATION
The trap macro for the SRsrcInfo function is _SlotManager ($A06E). The routine selector is $0016.
Trap macro Selector
_SlotManager $0016
You must setup register D0 with the routine selector and register A0 with the address of the Slot Manager parameter block. When _SlotManager returns, register D0 contains the result code.
Registers on entry
A0 address of the parameter block
D0 $0016
Registers on exit
D0 result code
RESULT CODES
noErr 0 No Error
smNoMoresRsrcs –344 Requested sResource data structure not found
SEE ALSO
For more information about the sResource data structure and fields of the sResource type, see “Firmware” on page 3-7.
For more control in finding sResource data structures, you can use the SGetSRsrc function, described on page 3-30, and the SGetTypeSRsrc function, described on page 3-33.
3SNextSRsrc
You can use the SNextSRsrc function to step through the sResource data structures on a card or from one card to the next.
FUNCTION SNextSRsrc (spBlkPtr: SpBlockPtr) : OSErr;
spBlkPtr Pointer to a Slot Manager parameter block.
<symbol\>\xac spsPointer Ptr A pointer to the sResource data structure.
<symbol\>\xac spIOReserved Integer Value of Slot Resource Table ioReserved field.
<symbol\>\xac spRefNum Integer The driver reference number.
<symbol\>\xac spCategory Integer Category field of sRsrcType.
<symbol\>\xac spCType Integer CType field of sRsrcType.
<symbol\>\xac spDrvrSW Integer DrvrSW field of sRsrcType.
<symbol\>\xac spDrvrHW Integer DrvrHW field of sRsrcType.
The SNextSRsrc function is similar to the SRsrcInfo function, except the SNextSRsrc function returns information about the sResource data structure that follows the requested one—that is, the one with the next entry in the sResource directory or the first sResource on the next card. The SNextSRsrc function skips disable sResources.
You specify a particular sResource data structure with the spSlot, spID, and spExtDev fields. The SNextSRsrc function finds the next sResource data structure, returns a pointer to it in the spsPointer field, and updates the spSlot, spID, and spExtDev fields to correspond to the sResource data structure it found. If there are no more sResource data structures, the SNextSRsrc function returns with a nonfatal status error.
The SNextSRsrc function returns other information about the sResource data structure in the spIoReserved, spRefNum, spCategory, spCType, spDrvrSW, and spDrvrHW fields.
SPECIAL CONSIDERATIONS
The SNextSRsrc function does not move memory; your application may call this function at interrupt time.
ASSEMBLY-LANGUAGE INFORMATION
The trap macro for the SNextSRsrc function is _SlotManager ($A06E). The routine selector is $0014.
Trap macro Selector
_SlotManager $0014
You must setup register D0 with the routine selector and register A0 with the address of the Slot Manager parameter block. When _SlotManager returns, register D0 contains the result code.
Registers on entry
A0 address of the parameter block
D0 $0014
Registers on exit
D0 result code
RESULT CODES
noErr 0 No Error
smNoMoresRsrcs –344 Requested sResource data structure not found
SEE ALSO
For more information about the sResource directory and the sResource data structure, see “Firmware” on page 3-7.
For more control in finding sResource data structures, you can use the SGetSRsrc function, described on page 3-30, and the SGetTypeSRsrc function, described on page 3-33.
3SGetSRsrc
You can use the SGetSRsrc function to find any sResource data structure, even one that has been disabled.
FUNCTION SGetSRsrc (spBlkPtr: SpBlockPtr) : OSErr;
spBlkPtr Pointer to a Slot Manager parameter block.
<symbol\>\xac spsPointer Ptr A pointer to the sResource data structure.
<symbol\>\xab spParamData LongInt On input: fAll, fOneslot, fNext flags.
The SGetSRsrc function allows you to specify whether the function should include disabled sResources, whether it should continue looking for sResources in higher-numbered slots, and whether it should return information about the specified sResource data structure or the one that follows it.
You specify an sResource data structure with the spSlot, spID, and spExtDev fields. You must also include flags in bits 0, 1, and 2 of the spParamData field as follows:
n Set the fAll flag (bit 0) to search both enabled and disabled sResource data structures. Clear this flag to search only enabled sResource data structures.
n Set the fOneslot flag (bit 1) to search only the specified slot. Clear this flag to search all slots.
n Set the fNext flag (bit 2) to return information about the sResource data structure with the next higher sResource ID than the specified sResource data structure (or the first one on the next card if the fAll flag is set). Clear this flag to return data about the specified sResource data structure.
The SGetSRsrc function returns values in the spSlot, spID, and spExtDev fields corresponding to the sResource data structure that it found. If you cleared the fNext flag, these fields retain the values you specified when calling the function. In addition, the function returns 0 in the spParamData field if the sResource data structure is enabled or 1 if it is disabled. If you cleared the fAll bit, the spParamData field always returns the value 0.
The SGetSRsrc function also returns a pointer to the sResource data structure in the spsPointer field and other information about the sResource data structure in the spRefNum, spCategory, spCType, spDrvrSW, spDrvrHW, and spHwDev fields.
SPECIAL CONSIDERATIONS
The SGetSRsrc function does not move memory; your application may call this function at interrupt time.
The SGetSRsrc function is available only with version 1 or later of the Slot Manager.
ASSEMBLY-LANGUAGE INFORMATION
The trap macro for the SGetSRsrc function is _SlotManager ($A06E). The routine selector is $000B.
Trap macro Selector
_SlotManager $000B
You must setup register D0 with the routine selector and register A0 with the address of the Slot Manager parameter block. When _SlotManager returns, register D0 contains the result code.
Registers on entry
A0 address of the parameter block
D0 $000B
Registers on exit
D0 result code
RESULT CODES
noErr 0 No Error
smNoMoresRsrcs –344 Requested sResource data structure not found
SEE ALSO
For more information about the sResource data structure, see the section “Firmware” on page 3-7.
For more control in finding sResource data structures, you can use the SGetSRsrc function, described on page 3-30, and the SGetTypeSRsrc function, described on page 3-33.
3SNextTypeSRsrc
You can use the SNextTypeSRsrc function to step through sResource data structures of one type.
FUNCTION SNextTypeSRsrc (spBlkPtr: SpBlockPtr) : OSErr;
spBlkPtr Pointer to a Slot Manager parameter block.
<symbol\>\xac spsPointer Ptr A pointer to the sResource data structure.
<symbol\>\xac spIOReserved Integer Value of Slot Resource Table ioReserved field.
The SNextTypeSRsrc function allows you to find the next sResource data structure, as does the SNextSRsrc function, but the SNextTypeSRsrc function also allows you to specify the type of sResource data structures to find. The SNextTypeSRsrc function skips disable sResources.
You specify an sResource data structure with the spSlot, spID, and spExtDev fields, and you specify the type of the sResource with the spCategory, spCType, spDrvrSW, and spDrvrHW fields. You must also use the spTBMask to specify which of these D fields should not be included in the search:
n Set bit 0 to ignore the DrvrHW field.
n Set bit 1 to ignore the DrvrSW field.
n Set bit 2 to ignore the cType field.
n Set bit 3 to ignore the Category field.
The SNextTypeSRsrc function returns values in the spSlot, spID, and spExtDev fields corresponding to the sResource data structure that it found, and it returns 0 in the spParamData field in that sResource is enabled or 1 if it is disabled.
The SNextTypeSRsrc function also returns a pointer to the sResource data structure in the spsPointer field and other information about the sResource data structure in the spIOReserved, spRefNum, spCategory, spCType, spDrvrSW, and spDrvrHW fields.
SPECIAL CONSIDERATIONS
The SNextTypeSRsrc function does not move memory; your application may call this function at interrupt time.
ASSEMBLY-LANGUAGE INFORMATION
The trap macro for the SNextTypeSRsrc function is _SlotManager ($A06E). The routine selector is $0015.
Trap macro Selector
_SlotManager $0015
You must setup register D0 with the routine selector and register A0 with the address of the Slot Manager parameter block. When _SlotManager returns, register D0 contains the result code.
Registers on entry
A0 address of the parameter block
D0 $0015
Registers on exit
D0 result code
RESULT CODES
noErr 0 No Error
smNoMoresRsrcs –344 Requested sResource data structure not found
SEE ALSO
For more information about the sResource data structure, see the section “Firmware” on page 3-7.
For information on enabling and disabling sResource data structures, see the “Enabling and Disabling sResource Data Structures” on page 3-15 and the description of the SetSRsrcState function on page 3-35.
3SGetTypeSRsrc
You can use the SGetTypeSRsrc function to step through sResource data structures of one type, including disabled ones.
FUNCTION SGetTypeSRsrc (spBlkPtr: SpBlockPtr) : OSErr;
spBlkPtr Pointer to a Slot Manager parameter block.
You specify values and receive return values in the Slot Manager parameter block.
<symbol\>\xac spsPointer Ptr A pointer to the sResource data structure.
<symbol\>\xab spParamData LongInt On input: fAll, fOneslot flags.
The SGetTypeSRsrc function allows you to find the next sResource data structure of a certain type, as does the SNextTypeSRsrc function, but the SGetTypeSRsrc function also allows you to find disabled sResource data structures and to limit searching to a single slot.
You specify an sResource data structure with the spSlot, spID, and spExtDev fields, and you specify the type of the sResource with the spCategory, spCType, spDrvrSW, and spDrvrHW fields. You must also use the spTBMask to specify which of these sRsrcType fields should not be included in the search:
n Set bit 0 to ignore the DrvrHW field.
n Set bit 1 to ignore the DrvrSW field.
n Set bit 2 to ignore the cType field.
n Set bit 3 to ignore the Category field.
You must also set the fAll flag of the spParamData field (bit 0) to search both enabled and disabled sResource data structures or clear this flag to search only enabled ones. Set the fOneslot flag (bit 1) to search only the specified slot or clear this flag to search all slots. This function does not use the fNext flag (bit 2) because it always searches for the next sResource data structure of the given type.
The SGetTypeSRsrc function returns values in the spSlot, spID, and spExtDev fields corresponding to the sResource data structure that it found, and it returns 0 in the spParamData field in that sResource is enabled or 1 if it is disabled.
The SGetTypeSRsrc function also returns a pointer to the sResource data structure in the spsPointer field and other information about the sResource data structure in the spRefNum, spCategory, spCType, spDrvrSW, spDrvrHW, and spHwDev fields.
SPECIAL CONSIDERATIONS
The SGetTypeSRsrc function does not move memory; your application may call this function at interrupt time.
The SGetTypeSRsrc function is available only with version 1 or later of the Slot Manager.
ASSEMBLY-LANGUAGE INFORMATION
The trap macro for the SGetTypeSRsrc function is _SlotManager ($A06E). The routine selector is $000C.
Trap macro Selector
_SlotManager $000C
You must setup register D0 with the routine selector and register A0 with the address of the Slot Manager parameter block. When _SlotManager returns, register D0 contains the result code.
Registers on entry
A0 address of the parameter block
D0 $000C
Registers on exit
D0 result code
RESULT CODES
noErr 0 No Error
smNoMoresRsrcs –344 Requested sResource data structure not found
SEE ALSO
For more information about the sResource data structure, see the section “Firmware” on page 3-7.
For information on enabling and disabling sResource data structures, see the “Enabling and Disabling sResource Data Structures” on page 3-15 and the description of the SetSRsrcState function on page 3-35.
Enabling, Disabling, Deleting, and Restoring sResource
Data Structures
The routines in this section are primarily for use by device drivers. The first routine enables and disables sResource data structures. The next two routines delete sResource data structures from and restore them to the Slot Resource Table.
3SetSRsrcState
You can use the SetSRsrcState function to select which sResource data structures are enabled.
FUNCTION SetSRsrcState (spBlkPtr: SpBlockPtr) : OSErr;
spBlkPtr Pointer to a Slot Manager parameter block.
<symbol\>\xae spParamData LongInt Enable or disable the resource.
<symbol\>\xae spSlot SignedByte The slot number.
<symbol\>\xae spId SignedByte The sResource ID.
<symbol\>\xae spExtDev SignedByte The external device identifier.
DESCRIPTION
The SetSRsrcState function enables or disables an sResource data structure. All of the Slot Manager routines recognize enabled sResource data structures, while only the SGetSRsrc and SGetTypeSRsrc functions can recognize disabled ones.
You specify the sResource data structure to enable or disable with the spSlot, spID, and spExtDev fields, and in the spParamData field you specify whether to enable or disable it. The Slot Manager enables the sResource data structure when this field has a value of 0 and disables it when the field has a value of 1.
SPECIAL CONSIDERATIONS
The SetSRsrcState function does not move memory; your application may call this function at interrupt time.
The SetSRsrcState function is available only with version 1 or later of the Slot Manager.
ASSEMBLY-LANGUAGE INFORMATION
The trap macro for the SetSRsrcState function is _SlotManager ($A06E). The routine selector is $0009.
Trap macro Selector
_SlotManager $0009
You must setup register D0 with the routine selector and register A0 with the address of the Slot Manager parameter block. When _SlotManager returns, register D0 contains the result code.
Registers on entry
A0 address of the parameter block
D0 $0009
Registers on exit
D0 result code
RESULT CODES
noErr 0 No Error
smNoMoresRsrcs –344 Requested sResource data structure not found
SEE ALSO
For more information about the sResource data structure, see the section “Firmware” on page 3-7.
For information on enabling and disabling sResource data structures, see the “Enabling and Disabling sResource Data Structures” on page 3-15 and the description of the SetSRsrcState function on page 3-35.
For information on finding disabled sResource data structures see the description of the SGetSRsrc function on “SGetSRsrc” on page 3-30 and the description of the SGetTypeSRsrc function on “SGetTypeSRsrc” on page 3-33.
3SDeleteSRTRec
You can use the SDeleteSRTRec function to remove an sResource data structure from the Slot Resource Table.
FUNCTION SDeleteSRTRec (spBlkPtr: SpBlockPtr) : OSErr;
spBlkPtr Pointer to a Slot Manager parameter block.
<symbol\>\xae spSlot SignedByte The slot number.
<symbol\>\xae spId SignedByte The sResource ID.
<symbol\>\xae spExtDev SignedByte The external device identifier.
SPECIAL CONSIDERATIONS
The SDeleteSRTRec function may move memory; your application should not call this function at interrupt time.
The SDeleteSRTRec function is available only with version 1 or later of the Slot Manager.
ASSEMBLY-LANGUAGE INFORMATION
The trap macro for the SDeleteSRTRec function is _SlotManager ($A06E). The routine selector is $0031.
Trap macro Selector
_SlotManager $0031
You must setup register D0 with the routine selector and register A0 with the address of the Slot Manager parameter block. When _SlotManager returns, register D0 contains the result code.
Registers on entry
A0 address of the parameter block
D0 $0031
Registers on exit
D0 result code
SEE ALSO
For more information about the Slot Resource Table, see “About the Slot Manager” on page 3-12.
For more information about restoring an sResource data structure to the Slot Resource Table, see the next section, which describes the InsertSRTRec function.
3InsertSRTRec
You can use the InsertSRTRec function to add an sResource data structure to the Slot Resource Table.
FUNCTION InsertSRTRec (spBlkPtr: SpBlockPtr) : OSErr;
spBlkPtr Pointer to a Slot Manager parameter block.
<symbol\>\xae spsPointer Ptr NIL.
<symbol\>\xae spParamData LongInt Enable or disable the sResource.
The InsertSRTRec function installs an sResource data structure from the firmware of a NuBus card into the Slot Resource Table. For example, if the user makes a selection in the Monitors control panel that requires your video card to switch to a new sResource data structure that was deleted by PrimaryInit code, you can use the InsertSRTRec function to restore that sResource data structure.
You specify an sResource data structure with the spSlot, spID, and spExtDev fields. You must set the spsPointer field to NIL. Set the spParamData field to 1 to disable the restored sResource data structure or to 0 to enable it.
If you place a valid device driver reference number in the spRefNum field, the Slot Manager updates the dCtlDevBase field in that device driver’s device control entry (that is, in the device control entry that has that driver reference number in the dCtlRefNum field). The dCtlDevBase field contains the base address of the memory buffer for data provided by the sResource data structure that is used by that device driver.
The Slot Manager calculates this address by using bit 2 (the f32BitMode flag) of the sRsrcFlags field of the sResource data structure. As shown in Table 3-4, the Slot Manager first checks the value of bit 2 of the sRsrcFlags. Then, it checks for a MinorBaseOS entry. If it finds one, it uses this value to create a 32-bit value to store in the dCtlDevBase field. If it does not find one, it uses the value in the MajorBaseOS entry.
How the Slot Manager determines the base address used by an sResource
sRsrcFlags MinorBaseOS MajorBaseOS Address format
Field missing $x xxxx Any or none $Fs0x xxxx
Field missing None $xx xxxx $sxxx xxxx
Bit 2 is 0 $x xxxx Any or none $Fs0x xxxx
Bit 2 is 0 None $xx xxxx $sxxx xxxx
Bit 2 is 1 $x xxxx Any or none $Fsxx xxxx
Bit 2 is 1 None $xx xxxx $sxxx xxxx
In this table, x represents any hexadecimal digit and s represents a slot number. <36pt\>\x12 <8bat\>u
SPECIAL CONSIDERATIONS
The InsertSRTRec function may move memory; your application should not call this function at interrupt time.
The InsertSRTRec function is available only with version 1 or later of the Slot Manager.
ASSEMBLY-LANGUAGE INFORMATION
The trap macro for the InsertSRTRec function is _SlotManager ($A06E). The routine selector is $000A.
Trap macro Selector
_SlotManager $000A
You must setup register D0 with the routine selector and register A0 with the address of the Slot Manager parameter block. When _SlotManager returns, register D0 contains the result code.
smNoMoresRsrcs –344 Specified sResource data structure not found
smBadsPtrErr –346 Bad pointer was passes to SCalcSPointer
smByteLanesErr –347 ByteLanes field in card’s format block was
determined to be zero
SEE ALSO
For more information about the sResource data structure, see the section “Firmware” on page 3-7.
For more information about the device control entry and device driver reference numbers, see the chapter “The Device Manager” in this volume.
Getting Information from sResource Data Structures
The Slot Manager provides a number of routines that simplify access to the information in sResource data structures. Most of these routines simply return the value of an sResource list entry.
3SReadDrvrName
You can use the SReadDrvrName function to read the name of an sResource data structure in a format you can use to open the driver with Device Manager routines.
FUNCTION SReadDrvrName (spBlkPtr: SpBlockPtr) : OSErr;
spBlkPtr Pointer to a Slot Manager parameter block.
<symbol\>\xae spSlot SignedByte The slot number.
<symbol\>\xae spID SignedByte The sResource ID.
<symbol\>\xae spResult LongInt Pointer to driver name.
5 spSize LongInt
5 spsPointer Ptr
DESCRIPTION
The SReadDrvrName function reads the name of an sResource data structure, prefixes a period to the value, and converts it to type Str255. The final driver name is compatible with the Device Manager’s OpenDriver function.
You specify the sResource data structure with the spSlot and spID fields. In your program, you should declare a Pascal string variable and pass a pointer to it in the spResult field.
The SReadDrvrName function returns the driver name by copying it into the string pointed to by the spResult field.
This function may alter the values of the spSize and spsPointer fields of the parameter block. Your application should not depend on the values returned in these fields.
SPECIAL CONSIDERATIONS
The SReadDrvrName function does not move memory; your application may call this function at interrupt time.
ASSEMBLY-LANGUAGE INFORMATION
The trap macro for the SReadDrvrName function is _SlotManager ($A06E). The routine selector is $0019.
Trap macro Selector
_SlotManager $0019
You must setup register D0 with the routine selector and register A0 with the address of the Slot Manager parameter block. When _SlotManager returns, register D0 contains the result code.
Registers on entry
A0 address of the parameter block
D0 $0019
Registers on exit
D0 result code
RESULT CODES
noErr 0 No Error
smNoMoresRsrcs –344 Requested sResource data structure not found
SEE ALSO
For more information about the sResource data structure, see the section “Firmware” on page 3-7.
For more information about the device control entry and device driver reference numbers, see the chapter “The Device Manager” in this volume.
3SOffsetData
You can use the SOffsetData function to determine the value of the offset field of an sResource list entry.
FUNCTION SOffsetData (spBlkPtr: SpBlockPtr) : OSErr;
spBlkPtr Pointer to a Slot Manager parameter block.
<symbol\>\xab spsPointer Ptr On input: Pointer to the sResource list.
On output: Pointer to sResource list entry.
<symbol\>\xac spOffsetData LongInt The contents of the offset field.
<symbol\>\xae spID SignedByte The ID of the sResource list entry.
<symbol\>\xac spByteLanes SignedByte Byte lanes from card format block.
5 spResult LongInt
5 spFlags SignedByte
DESCRIPTION
The SOffsetData function returns the contents of an offset field of an entry in an sResource list. This function provides low-level support for determining information in sResource list data structures. Many of the remaining routines in this section provide higher-level support.
You provide a pointer to the sResource list in the spsPointer field, and the ID of the entry in the spID field.
The SOffsetData function returns the value of the offset field, which can be a byte or a word of data or an offset to a larger block of data, in the spOffsetData field of the parameter block. The return value of the spsPointer field is a pointer to the specified entry in the sResource list—that is, an pointer to the entry’s ID field.
This function uses the spByteLanes field to return the value of the ByteLanes field from the format block of the card on which the sResource data structure resides.
Your application should not depend on the values returned in the spResult and spFlags fields.
SPECIAL CONSIDERATIONS
The SOffsetData function does not move memory; your application may call this function at interrupt time.
ASSEMBLY-LANGUAGE INFORMATION
The trap macro for the SOffsetData function is _SlotManager ($A06E). The routine selector is $0024.
Trap macro Selector
_SlotManager $0024
You must setup register D0 with the routine selector and register A0 with the address of the Slot Manager parameter block. When _SlotManager returns, register D0 contains the result code.
Registers on entry
A0 address of the parameter block
D0 $0024
Registers on exit
D0 result code
SEE ALSO
For more information about the sResource list data structure, see the “Introduction to Cards and Slots” section at the beginning of this chapter.
For information about routines that provide higher-level support for getting information from sResource lists, see the following reference sections which describe the SReadByte, SReadWord, SReadLong, SGetCString, SGetBlock, SReadStruct, and SFindStruct routines.
3SReadByte
You can use the SReadByte function to determine the value of the low-order byte of an sResource list entry.
FUNCTION SReadByte (spBlkPtr: SpBlockPtr) : OSErr;
spBlkPtr Pointer to a Slot Manager parameter block.
You specify values and receive return values in the Slot Manager parameter block.
<symbol\>\xac spResult LongInt Contents of the entry byte.
<symbol\>\xae spsPointer Ptr Pointer to the sResource list.
<symbol\>\xae spID SignedByte The ID of the sResource list entry.
5 spOffsetData LongInt
5 spByteLanes SignedByte
DESCRIPTION
You provide a pointer to the sResource list in the spsPointer field, and the ID of the entry in the spID field. The SReadByte function returns the data byte in the spResult field.
This function may alter the values of the spOffsetData and spByteLanes fields of the parameter block. Your application should not depend on the values returned in these fields.
SPECIAL CONSIDERATIONS
The SReadByte function does not move memory; your application may call this function at interrupt time.
ASSEMBLY-LANGUAGE INFORMATION
The trap macro for the SReadByte function is _SlotManager ($A06E). The routine selector is $0000.
Trap macro Selector
_SlotManager $0000
You must setup register D0 with the routine selector and register A0 with the address of the Slot Manager parameter block. When _SlotManager returns, register D0 contains the result code.
Registers on entry
A0 address of the parameter block
D0 $0000
Registers on exit
D0 result code
SEE ALSO
For more information about the sResource list data structure, see the section “Firmware” on page 3-7.
3SReadWord
You can use the SReadWord function to determine the value of the low-order word of an sResource list entry.
FUNCTION SReadWord (spBlkPtr: SpBlockPtr) : OSErr;
spBlkPtr Pointer to a Slot Manager parameter block.
<symbol\>\xac spResult LongInt Contents of the entry word.
<symbol\>\xae spsPointer Ptr Pointer to the sResource list.
<symbol\>\xae spID SignedByte The ID of the sResource list entry.
5 spOffsetData LongInt
5 spByteLanes SignedByte
SPECIAL CONSIDERATIONS
The SReadWord function does not move memory; your application may call this function at interrupt time.
ASSEMBLY-LANGUAGE INFORMATION
The trap macro for the SReadWord function is _SlotManager ($A06E). The routine selector is $0001.
Trap macro Selector
_SlotManager $0001
You must setup register D0 with the routine selector and register A0 with the address of the Slot Manager parameter block. When _SlotManager returns, register D0 contains the result code.
Registers on entry
A0 address of the parameter block
D0 $0001
Registers on exit
D0 result code
SEE ALSO
For more information about the sResource list data structure, see the section “Firmware” on page 3-7.
3SReadLong
You can use the SReadLong function to determine the value of a longword pointed to by the offset field of an sResource list entry.
FUNCTION SReadLong (spBlkPtr: SpBlockPtr) : OSErr;
spBlkPtr Pointer to a Slot Manager parameter block.
<symbol\>\xac spResult LongInt Contents of the longword.
<symbol\>\xae spsPointer Ptr Pointer to the sResource list.
<symbol\>\xae spID SignedByte The ID of the sResource list entry.
5 spSize LongInt
5 spOffsetData LongInt
5 spByteLanes SignedByte
DESCRIPTION
The SReadLong function returns the 32-bit value pointed to by the offset field of an sResource list entry.
You provide a pointer to the sResource list in the spsPointer field, and the ID of the entry in the spID field. The SReadLong function returns the longword value in the spResult field.
This function may alter the values of the spSize, spOffsetData, and spByteLanes fields of the parameter block. Your application should not depend on the values returned in these fields.
SPECIAL CONSIDERATIONS
The SReadLong function does not move memory; your application may call this function at interrupt time.
ASSEMBLY-LANGUAGE INFORMATION
The trap macro for the SReadLong function is _SlotManager ($A06E). The routine selector is $0002.
Trap macro Selector
_SlotManager $0002
You must setup register D0 with the routine selector and register A0 with the address of the Slot Manager parameter block. When _SlotManager returns, register D0 contains the result code.
Registers on entry
A0 address of the parameter block
D0 $0002
Registers on exit
D0 result code
SEE ALSO
For more information about the sResource list data structure, see the section “Firmware” on page 3-7.
3SGetCString
You can use the SGetCString function to determine the value of a string pointed to by the offset field of an sResource list entry.
FUNCTION SGetCString (spBlkPtr: SpBlockPtr) : OSErr;
spBlkPtr Pointer to a Slot Manager parameter block.
<symbol\>\xac spResult LongInt Pointer to copy of cString.
<symbol\>\xae spsPointer Ptr Pointer to the sResource list.
<symbol\>\xae spID SignedByte The ID of the sResource list entry.
5 spSize LongInt
5 spOffsetData LongInt
5 spByteLanes SignedByte
5 spFlags SignedByte
DESCRIPTION
The SGetCString function returns a copy of the cString data structure pointed to by the offset field of an sResource list entry.
You provide a pointer to the sResource list in the spsPointer field, and the ID of the entry in the spID field.
The SGetCString function allocates a memory buffer, copies the value of the cString data structure into it, and returns a pointer to it in the spResult field. You should dispose of this pointer using the Memory Manager routine DisposPtr.
This function may alter the values of the spSize, spOffsetData, spByteLanes, and spFlags fields of the parameter block. Your application should not depend on the values returned in these fields.
SPECIAL CONSIDERATIONS
The SGetCString function allocates memory; your application should not call this function at interrupt time.
ASSEMBLY-LANGUAGE INFORMATION
The trap macro for the SGetCString function is _SlotManager ($A06E). The routine selector is $0003.
Trap macro Selector
_SlotManager $0003
You must setup register D0 with the routine selector and register A0 with the address of the Slot Manager parameter block. When _SlotManager returns, register D0 contains the result code.
Registers on entry
A0 address of the parameter block
D0 $0003
Registers on exit
D0 result code
SEE ALSO
For more information about the cString data structure, see the section “Firmware” on page 3-7.
3SGetBlock
You can use the SGetBlock function to obtain a copy of an sBlock data structure pointed to by the offset field of an sResource list entry.
FUNCTION SGetBlock (spBlkPtr: SpBlockPtr) : OSErr;
spBlkPtr Pointer to a Slot Manager parameter block.
<symbol\>\xac spResult LongInt Pointer to copy of sBlock.
<symbol\>\xae spsPointer Ptr Pointer to the sResource list.
<symbol\>\xae spID SignedByte The ID of the sResource list entry.
5 spSize LongInt
5 spOffsetData LongInt
5 spByteLanes SignedByte
5 spFlags SignedByte
DESCRIPTION
The SGetBlock function returns a copy of the sBlock data structure pointed to by the offset field of an sResource list entry.
You provide a pointer to the sResource list in the spsPointer field, and the ID of the entry in the spID field.
The SGetBlock function allocates a memory buffer, copies the contents of the sBlock data structure into it, and returns a pointer to it in the spResult field. You should dispose of this pointer using the Memory Manager routine DisposPtr.
This function may alter the values of the spSize, spOffsetData, spByteLanes, and spFlags fields of the parameter block. Your application should not depend on the values returned in these fields.
SPECIAL CONSIDERATIONS
The SGetBlock function allocates memory; your application should not call this function at interrupt time.
ASSEMBLY-LANGUAGE INFORMATION
The trap macro for the SGetBlock function is _SlotManager ($A06E). The routine selector is $0005.
Trap macro Selector
_SlotManager $0005
You must setup register D0 with the routine selector and register A0 with the address of the Slot Manager parameter block. When _SlotManager returns, register D0 contains the result code.
Registers on entry
A0 address of the parameter block
D0 $0005
Registers on exit
D0 result code
SEE ALSO
For more information about the sBlock data structure, see the section “Firmware” on page 3-7.
For information on how to determine the size of an sBlock data structure, see the next section, which describes the SReadPBSize function.
3SReadPBSize
You can use the SReadPBSize function to determine the size of an sBlock data structure.
FUNCTION SReadPBSize (spBlkPtr: SpBlockPtr) : OSErr;
spBlkPtr Pointer to a Slot Manager parameter block.
<symbol\>\xab spsPointer Ptr Pointer to sResource list.
<symbol\>\xac spSize LongInt Size of the sBlock data structure.
<symbol\>\xab spsPointer Ptr Pointer to sResource lists.
<symbol\>\xae spID SignedByte ID of the sBlock in the sResource list.
<symbol\>\xac spByteLanes SignedByte Byte lanes from format block.
You provide a pointer to the sResource list in the spsPointer field and the ID of the sBlock entry in the spID field. You can also specify the fckReserved flag of the spFlags field.
The SReadPBSize function returns the physical size of the block in the spSize field and a pointer to the block in the spsPointer field.
This function uses the spByteLanes field to return the value of the ByteLanes field from the format block of the card on which the sResource data structure resides.
SPECIAL CONSIDERATIONS
The SReadPBSize function does not move memory; your application may call this function at interrupt time.
ASSEMBLY-LANGUAGE INFORMATION
The trap macro for the SReadPBSize function is _SlotManager ($A06E). The routine selector is $0026.
Trap macro Selector
_SlotManager $0026
You must setup register D0 with the routine selector and register A0 with the address of the Slot Manager parameter block. When _SlotManager returns, register D0 contains the result code.
Registers on entry
A0 address of the parameter block
D0 $00026
Registers on exit
D0 result code
SEE ALSO
For more information about the sBlock data structure, see the section “Firmware” on page 3-7.
3SFindStruct
The SFindStruct function allows you to obtain a pointer to any data structure pointed to by the offset field of an sResource list entry. You might want to use this function, for example, when the data structure type is defined by the card designer.
FUNCTION SFindStruct (spBlkPtr: SpBlockPtr) : OSErr;
spBlkPtr Pointer to a Slot Manager parameter block.
<symbol\>\xab spsPointer Ptr On input: pointer to the sResource list.
On output: pointer to data structure.
<symbol\>\xae spID SignedByte The ID of the sResource list entry.
5 spByteLanes SignedByte
DESCRIPTION
You provide a pointer to the sResource list in the spsPointer field, and the ID of the entry in the spID field.
The SFindStruct function returns a pointer to the data structure in the spResult field.
This function may alter the value of the spByteLanes field of the parameter block. Your application should not depend on the value returned in this field.
SPECIAL CONSIDERATIONS
The SFindStruct function does not move memory; your application may call this function at interrupt time.
ASSEMBLY-LANGUAGE INFORMATION
The trap macro for the SFindStruct function is _SlotManager ($A06E). The routine selector is $0006.
Trap macro Selector
_SlotManager $0006
You must setup register D0 with the routine selector and register A0 with the address of the Slot Manager parameter block. When _SlotManager returns, register D0 contains the result code.
Registers on entry
A0 address of the parameter block
D0 $0006
Registers on exit
D0 result code
SEE ALSO
For more information about the sResource list data structure, see the section “Firmware” on page 3-7.
For information about obtaining a copy of a data structure pointed to by the offset field of an sResource list entry, rather than a pointer to the data structure, see the next section, which describes the SReadStruct function.
3SReadStruct
The SReadStruct function allows you obtain a copy of any data structure offset from an sResource list entry. You might want to use this function, for example, when the data structure type is defined by the card designer.
FUNCTION SReadStruct (spBlkPtr: SpBlockPtr) : OSErr;
spBlkPtr Pointer to a Slot Manager parameter block.
You specify values and receive return values in the Slot Manager parameter block.
<symbol\>\xae spResult LongInt Pointer to memory block.
<symbol\>\xae spsPointer Ptr Pointer to the structure.
<symbol\>\xae spSize LongInt The length in bytes of the structure.
5 spByteLanes SignedByte
DESCRIPTION
The SReadStruct function copies any arbitrary data structure from the declaration ROM of an expansion card into memory.
You provide a pointer to the structure in the spsPointer field and the size of the structure in the spSize field. You must also allocate a memory block for the result and send a pointer to it in the spResult field.
The SReadStruct function copies the data structure into the memory block pointed to by the spResult field.
This function may alter the value of the spByteLanes field of the parameter block. Your application should not depend on the value returned in this field.
SPECIAL CONSIDERATIONS
The SReadStruct function does not move memory; your application may call this function at interrupt time.
ASSEMBLY-LANGUAGE INFORMATION
The trap macro for the SReadStruct function is _SlotManager ($A06E). The routine selector is $0007.
Trap macro Selector
_SlotManager $0007
You must setup register D0 with the routine selector and register A0 with the address of the Slot Manager parameter block. When _SlotManager returns, register D0 contains the result code.
Registers on entry
A0 address of the parameter block
D0 $0007
Registers on exit
D0 result code
SEE ALSO
For more information about the sResource list data structure, see the section “Firmware” on page 3-7.
For information about obtaining a pointer to a data structure pointed to by the offset field of an sResource list entry, rather than a copy of the data structure, see the previous section, which describes the SFindStruct function.
Loading Drivers and Executing Code from sResource
Data Structures
The routines in this section allow you to load the device driver associated with an sResource data structure or execute code from an SExecBlock data structure.
Both of the routines in this section require you to provide extra information in an SEBlock, or SExec parameter block, data structure, shown in Listing 3-5.
SEBlock (sExec parameter block) data structure
SEBlockPtr = ^SEBlock;
SEBlock = PACKED RECORD
seSlot: SignedByte; {Slot number}
sesRsrcID: SignedByte; {sResource ID}
seStatus: INTEGER; {Status of sExecBlock code}
seFlags: SignedByte; {Flags}
seFiller0: SignedByte; {Used for word alignment}
seFiller1: SignedByte; {Used for word alignment}
seFiller2: SignedByte; {Used for word alignment}
seResult: LONGINT; {Result of SLoad}
seIOFileName: LONGINT; {Pointer to IOFile name}
seDevice: SignedByte; {Which device to read from}
sePartition: SignedByte; {The partition}
seOSType: SignedByte; {Type of OS}
seReserved: SignedByte; {Reserved}
seRefNum: SignedByte; {Driver reference number}
seNumDevices: SignedByte; {Number of devices to load}
seBootState: SignedByte; {State of StartBoot code}
END;
3SGetDriver
You can use the SGetDriver function to load an sResource data structure’s device driver.
FUNCTION SGetDriver (spBlkPtr: SpBlockPtr) : OSErr;
spBlkPtr Pointer to a Slot Manager parameter block.
<symbol\>\xac spResult LongInt Pointer to memory block.
<symbol\>\xae spsExecPBlk Ptr Pointer to SEblock.
<symbol\>\xae spSlot SignedByte The slot number.
<symbol\>\xae spID SignedByte The sResource ID.
<symbol\>\xae spExtDev SignedByte The external device ID.
5 spSize SignedByte
5 spFlags SignedByte
DESCRIPTION
The SGetDriver function loads a device driver from an sResource data structure into memory.
You specify an sResource data structure with the spSlot, spID, and D fields, and provide a pointer to an SExecBlock in the spsExecPBlk field.
The SGetDriver function searches the sResource list for an sRsrcLoadRec entry. If it finds one, it loads the sLoadDriver record and executes it. If no sRsrcLoadRec entry exists, the SGetDriver function looks for an sRsrcDrvrDir entry. If it finds one, it loads the driver into memory.
The SGetDriver function returns a handle to the driver in the spResult field of the parameter block.
SPECIAL CONSIDERATIONS
The SGetDriver function may move memory; your application should not call this function at interrupt time.
ASSEMBLY-LANGUAGE INFORMATION
The trap macro for the SGetDriver function is _SlotManager ($A06E). The routine selector is $002D.
Trap macro Selector
_SlotManager $002D
You must setup register D0 with the routine selector and register A0 with the address of the Slot Manager parameter block. When _SlotManager returns, register A0 contains a handle to the loaded driver and register D0 contains the result code.
Registers on entry
A0 address of the parameter block
D0 $002D
Registers on exit
A0 handle to loaded driver
D0 result code
SEE ALSO
For more information about the sResource data structure, including the sRsrcDrvrDir and sRsrcLoadRec entry types, see Designing Cards and Drivers for the Macintosh Family.
3SExec
You can use the SExec function to execute code stored in an sExecBlock data structure.
FUNCTION SExec (spBlkPtr: SpBlockPtr) : OSErr;
spBlkPtr Pointer to a Slot Manager parameter block.
<symbol\>\xae spsPointer Ptr Pointer to sResource list.
<symbol\>\xae spsExecPBlk Ptr Pointer to SEBlock data structure.
<symbol\>\xae spID SignedByte ID of sExecBlock entry in sResource list.
5 spResult LongInt
DESCRIPTION
The SExec function loads SExecBlock code from an sResource list into the current heap zone, checks its revision level and CRC field, and executes the code.
You specify the SExecBlock by providing a pointer to the sResource list in the spsPointer field and the ID of the SExecBlock entry in the spID field. You must also provide in the spsExecPBlk field a pointer to an SExec parameter block. This data structure, shown in Listing 3-5, allows you to provide information about the execution of the SExecBlock code.
The SExec function passes the sExecBlock code a pointer to this data structure in register A0.
SPECIAL CONSIDERATIONS
The SExec function may move memory; your application should not call this function at interrupt time.
ASSEMBLY-LANGUAGE INFORMATION
The trap macro for the SExec function is _SlotManager ($A06E). The routine selector is $0023.
Trap macro Selector
_SlotManager $0023
You must setup register D0 with the routine selector and register A0 with the address of the Slot Manager parameter block. When _SlotManager returns, register D0 contains the result code.
Registers on entry
A0 address of the parameter block
D0 $0023
Registers on exit
D0 result code
SEE ALSO
For more information about the sResource data structure and the sExecBlock data structure, see the section “Firmware” on page 3-7.
For more information about device drivers, see the chapter “The Device Manager” of this volume.
Traversing Firmware of Expansion Cards
Because declaration ROMs may not use all four byte lanes, the difference between the addresses of two adjacent blocks may be greater than the size in bytes of the first block. The SCalcSPointer function can help you calculate the address of the next block in a declaration ROM, given a pointer to the current block and its size in bytes.
3SCalcSPointer
You can use the SCalcSPointer function to obtain a pointer to a given byte in a card’s declaration ROM.
FUNCTION SCalcSPointer (spBlkPtr: SpBlockPtr) : OSErr;
spBlkPtr Pointer to a Slot Manager parameter block.
<symbol\>\xab spsPointer Ptr Pointer to a byte in declaration ROM.
<symbol\>\xae spOffsetData LongInt Offset in bytes to desired pointer.
You specify the byte by providing a pointer to the current byte in the spsPointer field, an offset in bytes in the spOffset data field, and the valid byte lanes in the spByteLanes field.
The SCalcSPointer function returns the calculated pointer in the spsPointer field.
SPECIAL CONSIDERATIONS
The SCalcSPointer function does not move memory; your application may call this function at interrupt time.
ASSEMBLY-LANGUAGE INFORMATION
The trap macro for the SCalcSPointer function is _SlotManager ($A06E). The routine selector is $002C.
Trap macro Selector
_SlotManager $002C
You must setup register D0 with the routine selector and register A0 with the address of the Slot Manager parameter block. When _SlotManager returns, register D0 contains the result code.
Registers on entry
A0 address of the parameter block
D0 $002C
Registers on exit
D0 result code
SEE ALSO
For more information about the sResource list data structure, see the section “Firmware” on page 3-7.
Getting Information about Expansion Cards and
Declaration ROMs
The functions in this section return information about slot status, or information about entire declaration ROMs, instead of single sResource data structures.
The first two functions return information from the slot information record maintained by the Slot Manager for a particular slot. Listing 3-5 shows the definition of this data type.
SEBlock (SExec parameter block) data structure
TYPE SInfoRecPtr = ^SInfoRecord;
SInfoRecord = PACKED RECORD
siDirPtr: Ptr; {pointer to sResource directory}
siInitStatusA: INTEGER; {initialization error}
siInitStatusV: INTEGER; {status returned by vendor}
{ initialization routine}
siState: SignedByte; {initialization state}
siCPUByteLanes: SignedByte; {byte lanes used}
siTopOfROM: SignedByte; {highest valid address in ROM}
siStatusFlags: SignedByte ; {bit 0 is CardIsChanged flag}
siTOConstant: INTEGER; {Timeout constant for bus error}
siReserved: SignedByte; {reserved}
END;
3SFindSInfoRecPtr
You can use the SFindSInfoRecPtr function to obtain a pointer to the SInfoRecord data structure for a particular slot.
FUNCTION SFindSInfoRecPtr (spBlkPtr: SpBlockPtr) : OSErr;
spBlkPtr Pointer to a Slot Manager parameter block.
<symbol\>\xac spResult LongInt Pointer to the SInfoRecord data structure.
<symbol\>\xae spSlot SignedByte The slot number.
DESCRIPTION
You specify the slot with the spSlot parameter. You must also allocate an sInfoRecord data structure, and provide a pointer to it in the spResult field.
The SFindSInfoRecPtr function returns in the spResult field a pointer to the sInfoRecord data structure for the specified slot.
SPECIAL CONSIDERATIONS
The SFindSInfoRecPtr function does not move memory; your application may call this function at interrupt time.
ASSEMBLY-LANGUAGE INFORMATION
The trap macro for the SFindSInfoRecPtr function is _SlotManager ($A06E). The routine selector is $002F.
Trap macro Selector
_SlotManager $002F
You must setup register D0 with the routine selector and register A0 with the address of the Slot Manager parameter block. When _SlotManager returns, register D0 contains the result code.
Registers on entry
A0 address of the parameter block
D0 $002F
Registers on exit
D0 result code
SEE ALSO
For general information about the SInfoRecord data structure, see “About the Slot Manager” on page 3-12.
To obtain a copy of the SInfoRecord data structure, instead of a pointer to it, see the next section, which describes the SReadInfo function.
3SReadInfo
You can use the SReadInfo function to obtain a copy of the SInfoRecord data structure for a particular slot.
FUNCTION SReadInfo (spBlkPtr: SpBlockPtr) : OSErr;
spBlkPtr Pointer to a Slot Manager parameter block.
<symbol\>\xae spResult LongInt Pointer to an SInfoRecord data structure.
<symbol\>\xae spSlot SignedByte The slot number.
<zapf\>5 spSize LongInt
DESCRIPTION
The Slot Manager maintains an SInfoRecord data structure for each slot. The SReadInfo function copies the information from this data structure for the requested slot.
You specify the slot with the spSlot parameter. You must also allocate an SInfoRecord data structure, and provide a pointer to it in the spResult field. The SReadInfo function copies the information in the sInfo record maintained by the Slot Manager into the data structure pointed to by the spResult field.
This function may alter the contents of the spSize field. Your application should not depend on the value returned in this field.
SPECIAL CONSIDERATIONS
The SReadInfo function does not move memory; your application may call this function at interrupt time.
ASSEMBLY-LANGUAGE INFORMATION
The trap macro for the SReadInfo function is _SlotManager ($A06E). The routine selector is $0010.
Trap macro Selector
_SlotManager $0010
You must setup register D0 with the routine selector and register A0 with the address of the Slot Manager parameter block. When _SlotManager returns, register D0 contains the result code.
Registers on entry
A0 address of the parameter block
D0 $0010
Registers on exit
D0 result code
SEE ALSO
For general information about sInfoRecord data structures, see the “About the Slot Manager” section.
To obtain a pointer of the SInfoRecord data structure, instead of a copy of it, see the next section, which describes the SReadInfo function.
3SReadFHeader
You can use the SReadFHeader function to obtain a copy of the information in the format block of a declaration ROM.
FUNCTION SReadFHeader (spBlkPtr: SpBlockPtr) : OSErr;
spBlkPtr Pointer to a Slot Manager parameter block.
<symbol\>\xae spResult LongInt Pointer to an FHeaderRec data structure.
<symbol\>\xae spSlot SignedByte Slot number.
<zapf\>5 spsPointer Ptr
<zapf\>5 spSize LongInt
<zapf\>5 spOffsetData LongInt
<zapf\>5 spByteLanes SignedByte
DESCRIPTION
The SReadFHeader function copies the information from the format block of the expansion card in the requested slot to an FHeaderRec data structure you provide.
You specify the slot with the spSlot parameter. You must also allocate an FHeaderRec data structure, defined in Listing 3-7, and provide a pointer to it in the spResult field.
The SReadInfo function copies the information in the format block into the data structure pointed to by the spResult field.
This function may alter the contents of the spsPointer, spSize, spOffsetData, and spByteLanes fields. Your application should not depend on the values returned in these fields.
The FHeaderRec data structure
TYPE FHeaderRecPtr = ^FHeaderRec;
FHeaderRec = PACKED RECORD
fhDirOffset: LongInt; {offset to sResource directory}
fhLength: LongInt; {length in bytes of declaration ROM}
fhCRC: LongInt; {cyclic redundancy check}
fhROMRev: SignedByte; {declaration ROM revision}
fhFormat: SignedByte; {declaration ROM format}
fhTstPat: LongInt; {test pattern}
fhReserved: INTEGER; {reserved, should be $00}
fhByteLanes: SignedByte; {byte lanes used by declaration ROM}
END;
These fields correspond to fields of the format header, described in Designing Cards and Drivers for the Macintosh Family.
SPECIAL CONSIDERATIONS
The SReadFHeader function does not move memory; your application may call this function at interrupt time.
ASSEMBLY-LANGUAGE INFORMATION
The trap macro for the SReadFHeader function is _SlotManager ($A06E). The routine selector is $0013.
Trap macro Selector
_SlotManager $0013
You must setup register D0 with the routine selector and register A0 with the address of the Slot Manager parameter block. When _SlotManager returns, register D0 contains the result code.
Registers on entry
A0 address of the parameter block
D0 $0013
Registers on exit
D0 result code
SEE ALSO
For general information about the format block, see the section “Firmware” on page 3-7.
For information about the fields of the format block, see Designing Cards and Drivers for the Macintosh Family.
3SCkCardStat
You can use the SCkCardStat function to check the initialization status of an expansion card.
FUNCTION SCkCardStat (spBlkPtr: SpBlockPtr) : OSErr;
spBlkPtr Pointer to a Slot Manager parameter block.
<symbol\>\xae spSlot SignedByte The slot number.
<zapf\>5 spResult LongInt
DESCRIPTION
The SCkCardStat function checks the InitStatusA field of the SInfoRecord data structure for the expansion card in the designated slot.
You specify the slot with the spSlot parameter.
The SCkCardStat function returns the noErr constant if the InitStatusA field contains a nonzero value.
This function may alter the contents of the spResult field. Your application should not depend on the values returned in this field.
SPECIAL CONSIDERATIONS
The SCkCardStat function does not move memory; your application may call this function at interrupt time.
ASSEMBLY-LANGUAGE INFORMATION
The trap macro for the SCkCardStat function is _SlotManager ($A06E). The routine selector is $0018.
Trap macro Selector
_SlotManager $0018
You must setup register D0 with the routine selector and register A0 with the address of the Slot Manager parameter block. When _SlotManager returns, register D0 contains the result code.
Registers on entry
A0 address of the parameter block
D0 $0018
Registers on exit
D0 result code
SEE ALSO
For more information about the SInfoRecord data type, see “Getting Information about Expansion Cards and Declaration ROMs” on page 3-58.
3SCardChanged
You can use the SCardChanged function to determine if the card in a particular slot has been changed.
FUNCTION SCardChanged (spBlkPtr: SpBlockPtr) : OSErr;
spBlkPtr Pointer to a Slot Manager parameter block.
The SCardChanged function checks if the expansion card in a slot has been changed—that is, if its sPRAMInit record has been initialized.
You specify the slot with the spSlot parameter.
The SCardChanged function returns a value of TRUE in the spResult field of the parameter block if the card has changed.
SPECIAL CONSIDERATIONS
The SCardChanged function does not move memory; your application may call this function at interrupt time.
ASSEMBLY-LANGUAGE INFORMATION
The trap macro for the SCardChanged function is _SlotManager ($A06E). The routine selector is $0022.
Trap macro Selector
_SlotManager $0022
You must setup register D0 with the routine selector and register A0 with the address of the Slot Manager parameter block. When _SlotManager returns, register D0 contains the result code.
Registers on entry
A0 address of the parameter block
D0 $0022
Registers on exit
D0 result code
SEE ALSO
For more information about the SPRAMInit record, see the next section, “Getting Access to Expansion Cards’ Parameter RAM.”
Getting Access to Expansion Cards’ Parameter RAM
The Operating System reserves six bytes of parameter RAM for each slot. The routines in this section allow you to read or change the value of these bytes.
Both of the functions in this section use the SPRAMRecord data structure to contain the parameter RAM values.
The SPRAM Record data type
TYPE SPRAMRecPtr = ^SPRAMRecord;
SPRAMRecord = PACKED RECORD
boardID: INTEGER; {Apple-defined card ID}
vendorUse1: SignedByte; {Reserved for vendor use}
vendorUse2: SignedByte; {Reserved for vendor use}
vendorUse3: SignedByte; {Reserved for vendor use}
vendorUse4: SignedByte; {Reserved for vendor use}
vendorUse5: SignedByte; {Reserved for vendor use}
vendorUse6: SignedByte; {Reserved for vendor use}
END;
This data structure includes the Apple-defined BoardID and six bytes of parameter RAM information.
3SReadPRAMRec
You can use the SReadPRAMRec function to read the parameter RAM information for a particular slot.
FUNCTION SReadPRAMRec (spBlkPtr: SpBlockPtr) : OSErr;
spBlkPtr Pointer to a Slot Manager parameter block.
<symbol\>\xae spSlot SignedByte The slot number.
<symbol\>\xae spResult LongInt Pointer to SPRAMRecord data structure.
<zapf\>5 spSize LongInt
DESCRIPTION
The Operating System allocates one SPRAMRecord data structure for each slot in the system parameter RAM. The Slot Manager routine InitSPRAMRecs initializes this structure with the data from the sPRAMInit record on the firmware of the expansion card. The SReadPRAMRec function provides a copy of this information to your application.
You specify the slot number in the spSlot field. You must also allocate a SPRAMRecord data structure and send a pointer to it in the spResult field. The SReadPRAMRec function copies the appropriate parameter RAM information into this data structure.
SPECIAL CONSIDERATIONS
The SReadPRAMRec function does not move memory; your application may call this function at interrupt time.
ASSEMBLY-LANGUAGE INFORMATION
The trap macro for the SReadPRAMRec function is _SlotManager ($A06E). The routine selector is $0011.
Trap macro Selector
_SlotManager $0011
You must setup register D0 with the routine selector and register A0 with the address of the Slot Manager parameter block. When _SlotManager returns, register D0 contains the result code.
Registers on entry
A0 address of the parameter block
D0 $0011
Registers on exit
D0 result code
SEE ALSO
For more information about the sPRAMInit record, see Designing Cards and Drivers for the Macintosh Family.
3SPutPRAMRec
You can use the SPutPRAMRec function to change the values stored in a slot’s parameter RAM.
FUNCTION SPutPRAMRec (spBlkPtr: SpBlockPtr) : OSErr;
spBlkPtr Pointer to a Slot Manager parameter block.
<symbol\>\xae spsPointer Ptr Pointer to SPRAMRecord data structure.
<symbol\>\xae spSlot SignedByte The slot number.
DESCRIPTION
The SPutPRAMRec function allows you to change the values stored in the parameter RAM of a slot.
You specify the slot number with the spSlot field and provide the new parameter RAM values in a SPRAMRecord data structure pointed to by the spsPointer field.
The SPutPRAMRec function copies the information from the six vendor-use fields into the parameter RAM for the slot. This function does not copy the boardID field, which is Apple-defined.
SPECIAL CONSIDERATIONS
The SPutPRAMRec function does not move memory; your application may call this function at interrupt time.
ASSEMBLY-LANGUAGE INFORMATION
The trap macro for the SPutPRAMRec function is _SlotManager ($A06E). The routine selector is $0012.
Trap macro Selector
_SlotManager $0012
You must setup register D0 with the routine selector and register A0 with the address of the Slot Manager parameter block. When _SlotManager returns, register D0 contains the result code.
Registers on entry
A0 address of the parameter block
D0 $0012
Registers on exit
D0 result code
SEE ALSO
For more information about the sPRAMInit record, see the “Introduction to Cards and Slots” section at the beginning of this chapter.
Summary of the Slot Manager
Data Types
TYPE SpBlockPtr = ^SpBlock;
SpBlock = PACKED RECORD
spResult: LongInt; {result}
spsPointer: Ptr; {structure pointer}
spSize: LongInt; {size of structure}
spOffsetData: LongInt; {offset or data}
spIOFileName: Ptr; {reserved for Slot Manager}
spsExecPBlk: LongInt; {pointer to SEBlock data structure}
spParamData: Ptr; {flags}
spMisc: LongInt; {reserved for Slot Manager}
spReserved: LongInt; {reserved for Slot Manager}
spIOReserved: INTEGER; {ioReserved field from SRT}
spRefNum: INTEGER; {driver reference number}
spCategory: INTEGER; {Category field of sResource type}
spCType: INTEGER; {cType field of sResource type}
spDrvrSW: INTEGER; {DrvrSW field of sResource type}
spDrvrHW: INTEGER; {DrvrHW field of sResource type}
spTBMask: SignedByte; {sResource type bit mask}
spSlot: SignedByte; {slot number}
spID: SignedByte; {sResource ID}
spExtDev: SignedByte; {external device ID}
spHwDev: SignedByte; {hardware device ID}
spByteLanes: SignedByte; {valid byte lanes}
spFlags: SignedByte; {flags used by Slot Manager}
spKey: SignedByte; {reserved for Slot Manager}
END;
SInfoRecPtr = ^SInfoRecord;
SInfoRecord = PACKED RECORD
siDirPtr: Ptr; {pointer to sResource directory}
siInitStatusA: INTEGER; {initialization error}
siInitStatusV: INTEGER; {status returned by vendor}
{ initialization routine}
siState: SignedByte; {initialization state}
siCPUByteLanes: SignedByte; {byte lanes used}
siTopOfROM: SignedByte; {highest valid address in ROM}
siStatusFlags: SignedByte ; {bit 0 is CardIsChanged flag}
siTOConstant: INTEGER; {Timeout constant for bus error}
siReserved: SignedByte; {reserved}
END;
FHeaderRecPtr = ^FHeaderRec;
FHeaderRec = PACKED RECORD
fhDirOffset: LongInt; {offset to sResource directory}
fhLength: LongInt; {length in bytes of declaration ROM}
fhCRC: LongInt; {cyclic redundancy check}
fhROMRev: SignedByte; {declaration ROM revision}
fhFormat: SignedByte; {declaration ROM format}
fhTstPat: LongInt; {test pattern}
fhReserved: INTEGER; {reserved, should be $00}
fhByteLanes: SignedByte; {byte lanes used by declaration ROM}
END;
SPRAMRecPtr = ^SPRAMRecord;
SPRAMRecord = PACKED RECORD
boardID: INTEGER; {Apple-defined card ID}
vendorUse1: SignedByte; {Reserved for vendor use}
vendorUse2: SignedByte; {Reserved for vendor use}
vendorUse3: SignedByte; {Reserved for vendor use}
vendorUse4: SignedByte; {Reserved for vendor use}
vendorUse5: SignedByte; {Reserved for vendor use}
vendorUse6: SignedByte; {Reserved for vendor use}
END;
Routines
Determining the Version of the Slot Manager
FUNCTION SVersion (spBlkPtr: SpBlockPtr) : OSErr;
Finding sResource Data Structures
FUNCTION SFindSRsrcPtr (spBlkPtr: SpBlockPtr) : OSErr;
FUNCTION SGetSRsrcPtr (spBlkPtr: SpBlockPtr) : OSErr;
FUNCTION SRsrcInfo (spBlkPtr: SpBlockPtr) : OSErr;
FUNCTION SNextSRsrc (spBlkPtr: SpBlockPtr) : OSErr;
FUNCTION SGetSRsrc (spBlkPtr: SpBlockPtr) : OSErr;
FUNCTION SNextTypeSRsrc (spBlkPtr: SpBlockPtr) : OSErr;
FUNCTION SGetTypeSRsrc (spBlkPtr: SpBlockPtr) : OSErr;
Enabling, Disabling, and Restoring sResource Data Structures
FUNCTION SetSRsrcState (spBlkPtr: SpBlockPtr) : OSErr;
FUNCTION SDeleteSRTRec (spBlkPtr: SpBlockPtr) : OSErr;
FUNCTION InsertSRTRec (spBlkPtr: SpBlockPtr) : OSErr;
Getting Information from sResource Data Structures
FUNCTION SReadDrvrName (spBlkPtr: SpBlockPtr) : OSErr;
FUNCTION SOffsetData (spBlkPtr: SpBlockPtr) : OSErr;
FUNCTION SReadByte (spBlkPtr: SpBlockPtr) : OSErr;
FUNCTION SReadWord (spBlkPtr: SpBlockPtr) : OSErr;
FUNCTION SReadLong (spBlkPtr: SpBlockPtr) : OSErr;
FUNCTION SGetCString (spBlkPtr: SpBlockPtr) : OSErr;
FUNCTION SGetBlock (spBlkPtr: SpBlockPtr) : OSErr;
FUNCTION SReadPBSize (spBlkPtr: SpBlockPtr) : OSErr;
FUNCTION SFindStruct (spBlkPtr: SpBlockPtr) : OSErr;
FUNCTION SReadStruct (spBlkPtr: SpBlockPtr) : OSErr;
Loading Drivers and Executing Code from sResource Data Structures
FUNCTION SGetDriver (spBlkPtr: SpBlockPtr) : OSErr;
FUNCTION SExec (spBlkPtr: SpBlockPtr) : OSErr;
Traversing Firmware of Expansion Cards
FUNCTION SCalcSPtr (spBlkPtr: SpBlockPtr) : OSErr;
Getting Information about Expansion Cards and Declaration ROMs
FUNCTION SFindSInfoRec (spBlkPtr: SpBlockPtr) : OSErr;
FUNCTION SReadInfo (spBlkPtr: SpBlockPtr) : OSErr;
FUNCTION SReadFHeader (spBlkPtr: SpBlockPtr) : OSErr;
FUNCTION SCkCardStat (spBlkPtr: SpBlockPtr) : OSErr;
FUNCTION SCardChanged (spBlkPtr: SpBlockPtr) : OSErr;
Getting Access to Expansion Cards’ Parameter RAM
FUNCTION SReadPRAMRec (spBlkPtr: SpBlockPtr) : OSErr;
FUNCTION SPutPRAMRec (spBlkPtr: SpBlockPtr) : OSErr;
° d ONLN d = ∫H *—Intr ∑@ ° d ONLN d = HX ) oduction to Devices and Drivers ö† ° d ONLN d 8=mHz )£1-3 ° d ONLN d <J ∫U1 (R ∫About the Device Manager Æ ° d ONLN d VJEUR )ã1-4 ° d ONLN d ZW ∫b/ (_ ∫Using the Device Manager ‡ ° d ONLN d tWDbQ )ä1-7 ° d ONLN d xd ƒog (l ƒ"Opening and Closing Device Drivers ∞‡ ° d ONLN d úd{oà )∑1-8 ° d ONLN d †q ƒ| (y ƒCommunicating W d@ ° d ONLN d Øq|h )Tith Device Drivers ÁÄ ° d ONLN d √q||é )d1-10 ° d ONLN d »~ ƒâ › (Ü ƒContr Â@ ° d ONLN d Õ~ ›âÉ )$olling and Monitoring Device Drivers ÄÄ ° d ONLN d Û~òâ™ )ª1-13 ° d ONLN d ¯ã ∫ñ — (ì ∫Refer ⁄ ° d ONLN d ˝ã —ñK )ence to the Device Manager %† ° d ONLN dã`ñr )è1-15 ° d ONLN d ò ƒ£ Á († ƒData Str `` ° d ONLN d&ò Ë£ ˇ )$uctur Ê@ ° d ONLN d+ò ˇ£ )es χ ° d ONLN d/ò £. ) 1-15 ° d ONLN d4• ƒ∞ Î (≠ ƒRoutines ≠` ° d ONLN d>• ˇ∞ );1-18 ° d ONLN dC≤ ŒΩq (∫ Œ"Opening and Closing Device Drivers ∞‡ ° d ONLN dg≤ÖΩó )∑1-18 ° d ONLN dlø Œ ˛ (« Œ
Y ¥¿ ° d ONLN dŒ √û Œ’ ) ou would pr –@ ° d ONLN dŸ √’ Œ )7 obably not ° d ONLN d‰ œ ä ⁄ ( ◊ äUneed to use the Device Manager to communicate with a graphics device on an expansion ° d ONLN d9 € ä Ê ó * car µ@ ° d ONLN d< € ó ÊM )
'd, as you would use QuickDraw instead. A¿ ° d ONLN dc €N ÊT )∑Y @ ° d ONLN dd €T Ê˚ )&ou also do not need to use the Device ° d ONLN dä Á ä Ú ¡ ( Ô ä Manager dir [ ° d ONLN dï Á ¡ Ú )7Kectly to communicate with disk drives or printers, as you can use the File ° d ONLN d‡ Û ä ˛ ( ˚ ä Manager or the Printing Manager m` ° d ONLN dˇ Û ˛ )î. ° d ONLN d ä ê (
äT µ¿ ° d ONLN d è ‹ )o use this chapter w ° d ONLN d ‹b )M , you should be familiar with r œ ° d ONLN d3bz )Üesour @ ° d ONLN d8{¯ )ces and how the system sear +@ ° d ONLN dS¯
° d ONLN d⁄A ñL ƒ ) a brief intr ¡@ ° d ONLN dÊA ƒLé )..oduction to devices and device drivers (the pr ᇠ° d ONLN dAèL› )Àograms that contr §¿ ° d ONLN d%A›L )N ol devices)
° d ONLN d1U ä\ è ([ än
° d ONLN d3S ñ^’ ) Fa description of the Device Manager and how it manages device drivers
° d ONLN dzg än è (m än
° d ONLN d|e ñp[ ) +a discussion of how to use Device Manager r µ ° d ONLN dße[p )≈%outines to exchange information with ° d ONLN dÃq ñ| (y ñdevices and device drivers ° d ONLN dÁÉ äé ê (ã äY @Ä ° d ONLN dËÉ êé µ )ou can fi Ä ° d ONLN dÒÉ ∂é ‡ )& nd specifi Ê¿ ° d ONLN d˚É ‡ék )* c information about the standar g‡ ° d ONLN dÉlé )å%d Macintosh device drivers, like the ° d ONLN d?è äö˙ (ó äVDisk Driver and the Serial Drivers, in separate chapters of this book. If you want to ° d ONLN dïõ ä¶ í * cr µ@ ° d ONLN dóõ í¶^ )-eate your own device driver or desk accessory «Ä ° d ONLN dƒõ]¶ú )À, you should fi o ° d ONLN d”õù¶Æ )@rst r & ° d ONLN dÿõض )ead this chapter and ° d ONLN dÌß ä≤ § (Ø äthen r s¿ ° d ONLN dÛß §≤ ˘ )ead the chapter “W ;Ä ° d ONLN dß ˘≤ )Uriting Ù ° d ONLN d ß≤ )Y ¥† ° d ONLN d
ß≤ø )$our Own Device Driver” in this book.
∑ H“ 4∏ H“
„ HÎ 4‰ HÎ ‰ H‰
ˇ·ˇ‚7^
ˇˇ£‰ ˇÆ ° d ONLN d2– H‚S (fi H#Introduction to Devices and Drivers ˇˇˇˇˇˇ ⁄| (fi 1
)\om ° d ONLN dY ä# Õ ( äthe Macintosh. ‰Ä ° d ONLN dh Õ#≤ )C4An I/O device can transfer information in either dir ° d ONLN dú≤#œ )Âection. ° d ONLN d§* ä5c (2 ä1Devices transfer information in one of two ways. `‡ ° d ONLN d’*d5¥ )⁄Character devices ü` ° d ONLN dÊ*¥5∫ )P r ‰` ° d ONLN dË*∫5˘ )ead or write a ° d ONLN d˜6 äA ï (> ästr ƒ` ° d ONLN d˙6 ïA ) Weam of characters, or bytes, one at a time; they can neither skip bytes nor go back to ° d ONLN d QB äM ì (J äpr G ° d ONLN d SB îMX )
.evious bytes. The serial ports and printers ar ƒ` ° d ONLN d ÅBXM≠ )ƒe character devices. ° d ONLN d ñT ä_ » (\ ä
Block devices ˘¿ ° d ONLN d £T »_ Œ )> r >¿ ° d ONLN d •T œ_# )ead and write entir Z ° d ONLN d ∏T#_œ )T)e blocks of bytes at one time; they can r ˝ ° d ONLN d ·Tœ_ )¨
ead or write ° d ONLN d Ó` äke (h ä0any accessible block on demand. These devices ar k ° d ONLN d
`ek√ )€e usually used to stor { ° d ONLN d
4`√k· )^e and r ˆ‡ ° d ONLN d
;`·k ) etrieve ° d ONLN d
Cl äw (t äinformation. Disk drives ar ¿ ° d ONLN d
^lwG )xe block devices. ° d ONLN d
o~ äâ÷ (Ü äGDevices communicate with applications and with the Operating System thr ¶ ° d ONLN d
∂~÷â (Ü÷
ough special ° d ONLN d
√ä äï ì (í äpr G ° d ONLN d
≈ä îï ‘ )
ograms called u¿ ° d ONLN d
”ä ‘ï )@device drivers õ ° d ONLN d
·äï˙ )@6. These drivers act as translators, converting softwar Ä ° d ONLN d ä˙ï )Êe ° d ONLN d ñ ä° ç (û är E ° d ONLN d ñ é° ‘ )equests into har <‡ ° d ONLN d *ñ ‘° Î )Fdwar t† ° d ONLN d .ñ ΰ6 )e actions and har `† ° d ONLN d ?ñ6°M )Kdwar ò` ° d ONLN d CñM°´ )e actions into softwar ◊@ ° d ONLN d Yñ´°∂ )^e r ‡ ° d ONLN d \ñ∂°‘ ) esults. ˝ ° d ONLN d dñ‘°€ ) A 7† ° d ONLN d eñ‹°fi ) ° d ONLN d f¢ ä≠ (™ äsynchronous device driver ¿ ° d ONLN d ¢≠ñ )y completes each communication r Ω` ° d ONLN d û¢ñ≠à )ì equest befor œ‡ ° d ONLN d ™¢Ã≠◊ )6e r fiÄ ° d ONLN d ≠¢◊≠ˇ ) eturning ° d ONLN d ∂Æ äπ † (∂ äcontr >Ä ° d ONLN d ªÆ °π Î )ol to the system. <` ° d ONLN d ÕÆ Îπ ˚ )JAn U ° d ONLN d –Æ ˚πx )asynchronous device driver ⁄¿ ° d ONLN d ÍÆxπ )}" can initiate a data transfer and ˇ* @ ˇ ˇˇˇˇ @
° d ONLN d ] l h o ( e lr E ° d ONLN d ] p h ° ) eturn contr Z† ° d ONLN d ] ° h ˇ )1ol to the system befor Ä ° d ONLN d " ] h, )_ e the entir H@ ° d ONLN d - ], h ),,e transfer is complete. This type of device ° d ONLN d Y i l t ∞ ( q ldriver usually r I` ° d ONLN d i i ± t Ì )Eelies on interr »@ ° d ONLN d x i Ì t
)<upts fr È¿ ° d ONLN d i
t6 )
om its har 1` ° d ONLN d â i7 tN )-dwar i ° d ONLN d ç iN tÉ )
e device to r ›Ä ° d ONLN d ö iÉ t¥ )5 egain contr .Ä ° d ONLN d • iµ t€ )2
ol of the ° d ONLN d Ø u l Ä u ( } lpr G ° d ONLN d ± u v ÄT )
2ocessor and continue or complete the data transfer }` ° d ONLN d „ uT ÄV )fi. ° d ONLN d  á l í s ( è lA ∫† ° d ONLN d Ê á s í )Y device driver does not have to be associated with a device. In general, a device driver ° d ONLN d? ì l û á ( õ lis a pr lÄ ° d ONLN dF ì á û )ogram that conforms to a pr ° d ONLN da ì û )|edefi ÿ ° d ONLN df ì ûh )ned format and pr ä ° d ONLN dw ìi ûÁ )Qogramming interface. Many ° d ONLN dë ü l ™ ( ß l(device drivers take advantage of this pr W` ° d ONLN dπ ü ™0 )Øedefi ° d ONLN dæ ü1 ™« )"ned interface to perform tasks unr @ ° d ONLN d‡ ü« ™Ô )ñ
elated to ° d ONLN dÍ ´ l ∂+ ( ≥ l,actual physical devices. Desk accessories ar ć ° d ONLN d ´+ ∂‚ )ø*e an example of this kind of device driver Ä ° d ONLN d@ ´‚ ∂‰ )∑. ° d ONLN dB Ω l » — ( ≈ lSome device drivers ar \ ° d ONLN dX Ω — » È )ee stor _Ä ° d ONLN d^ Ω È »Ü )"ed in the Macintosh ROM; others ar ° d ONLN dÄ Ωá »ü )ûe stor † ° d ONLN dÜ Ωü »’ )
ed in driver ˇˇ
Æ . ° d ONLN dì … l ‘ p ( — l( ,
Courier ˇ˛\ ° d ONLN dî » p ‘ î )'DRVR' ˇˇ
Æ ° d ONLN dö … î ‘ û )$) r ` ° d ONLN dù … û ‘ µ )
esour 2n ° d ONLN d¢ … µ ‘ Ò )
ces, which ar * ° d ONLN dØ … Ò ‘Ë )<7e typically located in applications, system extension fi Ï ° d ONLN dÁ …Ë ‘˙ )˜les, . ° d ONLN dÏ ’ l ‡ ï ( › l and the fi W@ ° d ONLN dˆ ’ ñ ‡ ¥ )*rmwar 9‡ ° d ONLN d˚ ’ ¥ ‡ ) e of expansion car ¥ ° d ONLN d
’ ‡ )Ods. ÆÄ ° d ONLN d ’ ‡ )A È ° d ONLN d ’ ‡ ) i ° d ONLN d ’ ‡` )driver resource ¿ ° d ONLN d" ’a ‡Ó )E contains information about the ° d ONLN dB · l Ï á ( È ldriver ‡ ° d ONLN dH · á ÏÈ )R, including the driver name, and the code necessary for the driver to perform its ° d ONLN dö Ì l ¯S ( ı l3functions. The Device Manager must load a driver fr .† ° d ONLN dÕ ÌT ¯ì )Ëom its driver r ~ ° d ONLN d‹ Ìì ¯´ )?esour Δ` ° d ONLN d· Ì´ ¯Ú )ce into memory ° d ONLN d ˘ l É ( lbefor _† ° d ONLN dı ˘ É∂ )Ee your application or any part of the system can communicate with it. ° d ONLN d; lÓ ( lVThe Device Manager opens certain device drivers at system startup time. These drivers ° d ONLN dë l" • * make up the ` ° d ONLN dù ¶" ):standard device drivers ≥† ° d ONLN d¥"ö )j , which include the Disk Driver ë` ° d ONLN d”ö" )ä, the Serial Drivers, ° d ONLN dÈ# l.õ (+ lBand printer drivers. The Device Manager opens other drivers when r Å` ° d ONLN d+#õ.ı (+õequested—typically . ° d ONLN d>/ l: ¡ (7 lby initialization ( ° d ONLN dQ. ¡:  )U'INIT' ° d ONLN dW/ Â: )$) r R` ° d ONLN dZ/ : ) esour $¿ ° d ONLN d_/:Æ )%ces, applications, and other drivers.
? *Z¯ 4@ *Z¯
k *s¯ 4l *s¯ l *l˛
ˇ·ˇ‚7^
ˇˇ£‰ . ˇÆ ° d ONLN dÖX *j ˆ (f *About the Device Manager ˇˇˇˇˇˇ ⁄| (fÓ1
° d ONLN dû| lá ‘ (Ñ lThe Device Manager pr d@ ° d ONLN d≥| ‘á )h
° d ONLN d“é xô ã ) It pr h ° d ONLN d◊é ãô  )ovides a common pr ™@ ° d ONLN dÈé ÂôÒ )Z;ogramming interface for applications and other managers to ° d ONLN d$ö x•D (¢ x+use when communicating with device drivers.
Figure 1-1 ° d ONLN d \ Ã g? )BCommunication with Devices
° d ONLN d j äu ° (r äBefor Û¿ ° d ONLN d j °u )Me the Device Manager allows an application or another manager to communicate ° d ONLN d mv äÅ ‚ (~ äwith a device driver ú‡ ° d ONLN d Åv ‚Å: )X, the driver must be @ ° d ONLN d ñv;ÅQ )Yopen E‡ ° d ONLN d övRÅ )%, which means the Device Manager has ° d ONLN d øÇ äç ç (ä är E ° d ONLN d ¿Ç éç Ω ) eceived a r ÅÄ ° d ONLN d ÀÇ Ωç+ )/equest to open the driver x ° d ONLN d ‰Ç+ç )n0, has loaded the driver into memory if necessary g¿ ° d ONLN dǡç )‘, ° d ONLN dé äô. (ñ ä&and has successfully called the driver 9 ° d ONLN d<é0ôd )¶ ’s opening r ]¿ ° d ONLN dHédôÇ )4outine. ° d ONLN dP† ä´ (® ä When opening a device driver ë† ° d ONLN dl†´w )Ö, the Device Manager cr † ° d ONLN dɆx´ò )ieates a @ ° d ONLN dã†ò´Ú ) device control entry ü@ ° d ONLN dü†Ú´ )Z (DCE), ° d ONLN dߨ ä∑m (¥ ä2which contains information about the device driver ο ° d ONLN dŸ¨l∑Û )‚ . For example, the device contr ' ° d ONLN d¯¨Ù∑˛ )àol ° d ONLN d˚∏ ä√¯ (¿ äVentry contains a handle to the device driver code (or a pointer for device drivers in ° d ONLN dQƒ äœ ∞ * ROM). T
device driver I¿ ° d ONLN d≥– ƒ€y ):., but it is possible for multiple entries to r ‡ ° d ONLN d·–z€› )∂efer to the same driver ˛` ° d ONLN d¯–‹€fi )b. ° d ONLN d˙‚ äÌ\ (Í ä-The Device Manager maintains another data str ∑ ° d ONLN d'‚\Ìs )“uctur <‡ ° d ONLN d,‚tÌé )e, the c‡ ° d ONLN d3‚é̺ ) unit table, † ° d ONLN d>‚ΩÌ‘ )/ to or ˘ ° d ONLN dD‚”Ì ) ganize the ° d ONLN dOÓ ä˘ ¿ (ˆ ä device contr l` ° d ONLN d[Ó ¿˘Œ )6@ol entries. The unit table contains a handle to the device contr &† ° d ONLN dõÓœ˘ (ˆœ
ol entry for ° d ONLN d®˙ ä ‘ ( äeach open driver 9¿ ° d ONLN d∏˙ ‘@ )J. The location of a driver @ ° d ONLN d“˙AÄ )m’s device contr Ö‡ ° d ONLN d·˙Ä )?%ol entry in the unit table is called ° d ONLN d ä µ ( ä
the driver Ù ° d ONLN d ∂ ø ),’s x@ ° d ONLN d ¿ ˘ )
unit number 4† ° d ONLN d ˘ ˛ )9. ° d ONLN d! ä# ( ä When you open a device driver ‘Ä ° d ONLN d>#x )ä, the Device Manager r ÿ@ ° d ONLN dTx#û )d eturns a Ï` ° d ONLN d]û#
)&driver reference number ¿ ° d ONLN dt# )p ° d ONLN du$ ä/ ƒ (, äfor the driver µ@ ° d ONLN dÉ$ ƒ/ … ):. ᆠ° d ONLN dÖ$ …/ œ )Y H ° d ONLN dÜ$ œ/ )ou use the driver r Œ ° d ONLN dô$ /0 )Qefer z@ ° d ONLN dù$1/j ) ence number ° d ONLN d®$j/Û )9!, instead of the driver name, to ° d ONLN d…0 ä;i (8 ä1identify the driver in subsequent communication r b¿ ° d ONLN d˙0i;√ )flequests. The driver r ,† ° d ONLN d0ƒ;‘ )[efer ÿ¿ ° d ONLN d0‘; ) ence number ° d ONLN d < äG ó (D äis r Í` ° d ONLN d#< óG{ )
3elated to the unit number by the following formula: ° d ONLN dW` äk1 (h ä$The Device Manager also maintains a ~‡ ° d ONLN d{`2kê )®driver request queue w` ° d ONLN dè`ëk )_ for each open device driver ° d ONLN d´` k ){. ° d ONLN d≠l äw- (t ä&At the head of this queue is the I/O r Ï@ ° d ONLN d”l-w^ )£ equest curr N ° d ONLN dfil_wú )2ently being pr @ ° d ONLN dÏlùw˛ )>ocessed by the device ° d ONLN dx äÉ • (Ä ädriver ‡ ° d ONLN dx •É ¡ ). The r † ° d ONLN dx ¡Éo ) 'est of the queue contains pending I/O r «† ° d ONLN d6xoÉù )Æ equests—r |Ä ° d ONLN d?xûÉÚ )/equests the Device ° d ONLN dRÑ äè … (å ä
Manager has r Â` ° d ONLN d_Ñ …èä )?-eceived but not yet sent to the device driver K¿ ° d ONLN dåÑäè˘ )¡. This queue allows your ° d ONLN d•ê äõ Õ (ò äapplication to r ≥¿ ° d ONLN dµê Õõ˛ )CEequest a data transfer with a busy device and accomplish other tasks ° d ONLN d˙ú äß Ó (§ äwhile the device satisfi ˇÄ ° d ONLN dú Óß )des pr M@ ° d ONLN dúß' )evious r § ° d ONLN d ú'ßJ )#equests.
w äQ 4 w äQ
w äQè 4 v â w ä ò " @ @ w ä ∂è fl fl ˝ @‰ ˝ ‡‰ ˛ ‰ ˛ ¯‰ ˛ ¸‰ ˛ ˛‰ ˛ ˇ‰ ˛ ?ˇÄ ˛ ˇ¿Â ˛ ˇˇ‡Â ˇˇÂ ˇˇ¯Â ˇˇ¸Â ˇˇ˛Â ˛ˇÂ
ˇ ˇˇ ˇˇ ˇˇ˛ ˇ˘ ˇˇ˝ ˇ ˇˇÅ Œ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ òÅ @ Ä H H P˝, ¡Ä ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê @ Ä⁄ äè ' Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ òÅ Ä ¿ H H P˝( ¬Ä ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê Ä ¿ äYè ' Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ òÅ ¿ H H P˝, √Ä ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê ¿ Y äòè ' Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ òÅ & H H P˝( ƒÄ ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê &ò äæè ' Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚ Å Å ˚
L äZ} , Times Ö ° d ONLN dˇˇ (V îU åw ° d ONLN dˇˇ )n ˛ ° d ONLN dˇˇ )i b≈ ° d ONLN dˇˇ )t ±å ° d ONLN dˇˇ )N ‰ì ° d ONLN dˇˇ )u l ° d ONLN dˇˇ )m +¡ ° d ONLN dˇˇ )b ≥H ° d ONLN dˇˇ )e ´ ° d ONLN dˇˇ )r
»L ° d ONLN dˇˇ )1 , Symbol / ° d ONLN dˇˇ (V Ÿ-
° d ONLN dˇˇ )D €µ ° d ONLN dˇˇ )r F‹ ° d ONLN dˇˇ )i ï£ ° d ONLN dˇˇ )v çj ° d ONLN dˇˇ )e Ö1 ° d ONLN dˇˇ )r X ° d ONLN dˇˇ )R ìü ° d ONLN dˇˇ )e ãf ° d ONLN dˇˇ )f ⁄- ° d ONLN dˇˇ )e —Ù ° d ONLN dˇˇ )r = ° d ONLN dˇˇ )e 4‚ ° d ONLN dˇˇ )n ºi ° d ONLN dˇˇ )c ¥0 ° d ONLN dˇˇ )e ´˜ ° d ONLN dˇˇ )N fi˛ ° d ONLN dˇˇ )u fÖ ° d ONLN dˇˇ )m &, ° d ONLN dˇˇ )b ≠≥ ° d ONLN dˇˇ )e •z ° d ONLN dˇˇ )r
˘ö ° d ONLN dˇˇ )
1 … ° d ONLN dˇˇ (Va+ 8à ° d ONLN dˇˇ (V Ó( fi, ° d ONLN dˇˇ )) àL ° d ONLN dˇˇ (V Â¥ Ø ° d ONLN dˇˇ (V –= ˇ#Ï @ ˇ ˇˇˇˇ @
° d ONLN d ] l h v ( e lW Û` ° d ONLN d ] u h á ) ith r 4Ä ° d ONLN d ] à h „ )espect to the driver r m ° d ONLN d ] „ h„ )[7equest queue, the Device Manager allows you make to thr º† ° d ONLN d S ]„ hÔ ( e„ee ° d ONLN d V i l t ï ( q l
types of r ˆ ° d ONLN d ` i ï t ÿ ))equests: synchr |† ° d ONLN d o i Ÿ t )Donous, asynchr !@ ° d ONLN d } i tÅ )Conous, and immediate. ° d ONLN d ì { l Ü ö ( É l
The terms K` ° d ONLN d ù { õ Ü ∂ )/synchr Ü ° d ONLN d £ { ∂ Ü Õ )onous h` ° d ONLN d ® { Œ Ü „ ) and UÄ ° d ONLN d ≠ { ‰ Ü )asynchr ` ° d ONLN d ¥ { Ü ) onous ‚¿ ° d ONLN d π { ÜA ) have dif N` ° d ONLN d ¬ {B ÜN )'fer 0‡ ° d ONLN d ≈ {N Ü„ ) ent meanings depending on their ° d ONLN d  á l í ë ( è l context. ° d ONLN d Ô ô l § å *When r 1` ° d ONLN d ı ô ç § ˇ )!eferring to a device driver H@ ° d ONLN d ô ˇ §+ )r , the term ¯@ ° d ONLN d ô+ §F ),synchr 2‡ ° d ONLN d! ôG §^ ) onous @ ° d ONLN d& ô_ §Õ ) indicates that the driver ° d ONLN dA • l ∞ ¿ ( ≠ lcompletes the entir ü ° d ONLN dT • ¿ ∞ À )Te r ≠† ° d ONLN dW • À ∞ ) equest befor ¿ ° d ONLN dc • ∞ )6e r Œ¿ ° d ONLN df • ∞K ) eturning contr -@ ° d ONLN dt •L ∞∫ )@ol to the Device Manager D` ° d ONLN då •∫ ∞È )n . The term ° d ONLN dó ± l º ã ( π lasynchr *‡ ° d ONLN dû ± å º £ ) onous
@ ° d ONLN d£ ± § ºI )' indicates that the driver can begin pr 4 ° d ONLN d ±I º| )• ocessing a r k@ ° d ONLN d÷ ±| º≤ )3 equest and r –@ ° d ONLN d‚ ±≤ º„ )6 eturn contr ‡ ° d ONLN dÌ ±„ ºÌ )1ol ° d ONLN d Ω l » È ( ≈ lto the Device Manager befor ÷@ ° d ONLN d Ω È » )}e the r B@ ° d ONLN d Ω »Ÿ ) 0equest is complete. When a driver is handling a ° d ONLN dB … l ‘ o ( — lr E ° d ONLN dC … p ‘ ≤ )equest asynchr ° d ONLN dQ … ≤ ‘ ’ )Bonously x@ ° d ONLN dX … ‘ ‘ )", it usually r ° d ONLN df … ‘E )5elies on interr í ° d ONLN du …E ‘b )<upts fr ≥Ä ° d ONLN d| …b ‘ë )
eferring to r √Ä ° d ONLN d Á ¡ Ú )4equests, the terms †` ° d ONLN d› Á Ú. )Rsynchr € ° d ONLN d„ Á. ÚE )onous Ω` ° d ONLN dË ÁF Ú[ ) and ™Ä ° d ONLN dÌ Á\ Ú{ )asynchr U` ° d ONLN dÙ Á| Úì ) onous 7¿ ° d ONLN d˘ Áî Ú‚ ) indicate how the ° d ONLN d Û l ˛ ¿ ( ˚ lDevice Manager pr (Ä ° d ONLN d Û ¡ ˛ ¯ )U
ocesses the r ˙‡ ° d ONLN d) Û ˜ ˛ )6equest. O` ° d ONLN d1 Û ˛> )"Actually Ä ° d ONLN d9 Û> ˛œ )%", you can specify that the Device ° d ONLN d[ ˇ l
† ( l
Manager pr Y ° d ONLN de ˇ †
Õ )4 ocess the r $‡ ° d ONLN dp ˇ Œ
# ).equest in one of thr D ° d ONLN dÑ ˇ#
H )Uee ways. ,
Zapf Dingbats
° d ONLN dç l q ( ln
° d ONLN dè x fl ) Synchronous requests. À¿ ° d ONLN d§ fl Q )g When you make a synchr î¿ ° d ONLN dªR s )sonous r ⁄@ ° d ONLN d¬s Ô )!equest, the Device Manager ° d ONLN d› x( ± (% x
places your r §¿ ° d ONLN dÍ ±(; )9!equest at the end of the driver r s ° d ONLN d <(Ô )ã&equest queue. The Device Manager then ° d ONLN d1) x4/ (1 x*waits until the driver has handled every r ˚‡ ° d ONLN d[)/4« )∑#equest in the queue, including the ° d ONLN d~5 x@ ï (= xsynchr $ ° d ONLN dÑ5 ñ@ fl ) onous one, befor î¿ ° d ONLN dî5 fl@ Í )Ie r £` ° d ONLN dó5 Í@) ) eturning contr ‡ ° d ONLN d•5*@ø )@#ol to your application. Notice ther ò@ ° d ONLN d»5ø@Û )ï e can never ° d ONLN d‘A xL ó (I xbe mor _¿ ° d ONLN d⁄A óL  ) e than one synchr C ° d ONLN dÎA ÂL )Nonous r à† ° d ONLN dÚALX )!equest per driver r ò ° d ONLN dAXLÊ )R equest queue at any given time. ° d ONLN d%M xX ˘ (U x (The driver can handle each r Î@ ° d ONLN dBM ˘Xo )Åequest in the queue synchr ° d ONLN d\MpXƒ )wonously or asynchr ò@ ° d ONLN dnMƒXÁ )Tonously ÙÄ ° d ONLN duMÊXÎ )", ° d ONLN dwY xd (a x!but the Device Manager does not r ˆ ° d ONLN dòYdA )ò eturn contr † ° d ONLN d£YBd— )2"ol to your application until the fi ¨` ° d ONLN dΔY—d· )ènal ° d ONLN d e xp { (m xr E ° d ONLN dÀe |p ” )equest is complete.)
° d ONLN d‡y lÄ q ( ln
° d ONLN d‚w xÇ Â ) Asynchronous requests. ÁÄ ° d ONLN d¯w ÂÇb )m When you make an asynchr Ň ° d ONLN dwcÇÑ )~onous r «` ° d ONLN dwÑÇ÷ )!equest, the Device ° d ONLN d+É xé € (ã xManager places your r ∂¿ ° d ONLN d@É €ée )c!equest at the end of the driver r Ö ° d ONLN daÉfé√ )ãequest queue, but it r ≥Ä ° d ONLN dwÉ√é· )]eturns ° d ONLN d~è xö é (ó xcontr >Ä ° d ONLN dÉè èö| )4ol to your application immediately—potentially befor *` ° d ONLN d∑è|öó )Ìe the r ñ` ° d ONLN dæèóöŸ )equest is satisfi ° d ONLN dœè⁄öÈ )Ced. ° d ONLN d”õ x¶ ~ (£ xY @Ä ° d ONLN d‘õ ~¶ ’ )our application is fr $‡ ° d ONLN dÈõ ’¶® )W1ee to perform other tasks while the driver satisfi ˙@ ° d ONLN dõ®¶« )”es the r £@ ° d ONLN d#õ»¶ˆ ) equests in ° d ONLN d.ß x≤
(Ø x its queue. The Device Manager pr ܆ ° d ONLN dNß
≤à )ï*ovides mechanisms for your application to ° d ONLN dx≥ xæ (ª x$determine when the driver has satisfi ı@ ° d ONLN dù≥ æ= )§ed the r } ° d ONLN d•≥>æ_ )"equest.
° d ONLN dÆ« lŒ q (Õ ln
° d ONLN d∞≈ x– ‘ ) Immediate requests. =‡ ° d ONLN d√≈ ’–p )]! When you call a Device Manager r ` ° d ONLN d‰≈p–Δ )õoutine immediately •† ° d ONLN dˆ≈≈–⁄ )U, the ° d ONLN d¸— x‹ ˙ (Ÿ xDevice Manager sends your r UÄ ° d ONLN d— ˙‹& )Ç
equest dir QÄ ° d ONLN d!—&‹t ),ectly to the driver ˆ` ° d ONLN d4—s‹’ )M, bypassing the driver ° d ONLN dK› xË { ( xr E ° d ONLN dL› |Ë “ )equest queue, and r ‰† ° d ONLN d_› “Ë )V eturns contr 7@ ° d ONLN dk›Ëô )6!ol to your application when the r h ° d ONLN då›ôËÔ )ëequest is complete. ° d ONLN d†È xÙ ™ (Ò x
An asynchr <¿ ° d ONLN d™È ´Ù )3onous device driver á ° d ONLN dΩÈÙ@ )W, which can pr ‚ ° d ONLN dÀÈ@Ù… )> ocess a single communication r 8‡ ° d ONLN dÈÈ ÙÙ )ä
equest in ° d ONLN dÛı x H (˝ x/a number of steps, might be in the middle of pr ø‡ ° d ONLN d "ıH ò )–ocessing another r ° d ONLN d 4ıô ∫ )Qequest. bÄ ° d ONLN d <ı∫ ¡ )!A ù ° d ONLN d =ı¡ ‰ ) similar ° d ONLN d F x ( x%situation can exist even for a synchr g ° d ONLN d k È )û.onous device driver if you make the immediate ° d ONLN d ô
x { ( xr E ° d ONLN d ö
| ‘ )equest during interr Ì@ ° d ONLN d Æ
‘’ )X<upt time. Device drivers that can handle this situation corr ¶ ° d ONLN d Í
÷Ì (÷ectly ° d ONLN d x$ Ä (! xar E ° d ONLN d Ú Å$ § ) e called 5 ° d ONLN d ˚ •$ Œ )$ reentrant €Ä ° d ONLN d
Œ$ ı ))
drivers. ì` ° d ONLN d
ı$g )'As some device drivers ar ‡ ° d ONLN d
'g$É )re not r ¿ ° d ONLN d
.Ñ$‚ ) eentrant, you should ° d ONLN d
C% x0 ◊ (- xalways check a driver ,¿ ° d ONLN d
X% Ÿ0? )a’s documentation befor <@ ° d ONLN d
n%?0† )fe making immediate r a ° d ONLN d
Ç%†0√ )aequests. ° d ONLN d
ã7 lB3 (? l+The next section, “Using the Device Manager ¯¿ ° d ONLN d
∂72BÍ )Δ*,” describes how to specify the manner in ° d ONLN d
‡C lN (K l"which the Device Manager should pr g` ° d ONLN d CNE )§ ocess your r T ° d ONLN d CENd )5equest. ° d ONLN d U l` ± (] lThe chapter “W ¿¿ ° d ONLN d $U ±` À )Eriting y` ° d ONLN d +U Ã` “ )Y 9‡ ° d ONLN d ,U “`§ )-our Own Device Driver” in this book gives mor ° d ONLN d YU§`‚ )“e information ° d ONLN d ga ll (i l!about the Device Manager data str ¡Ä ° d ONLN d àal )òuctur G` ° d ONLN d ça l’ ))es and also describes the Device Manager ° d ONLN d ∂m lx o (u lr E ° d ONLN d ∑m px$ )*outines useful for writing device drivers. ˇ ú @ ˇ ˇˇˇˇ @
ˇˇ£‰ ˇÆ ° d ONLN d v H à ( Ñ HUsing the Device Manager ˇˇˇˇˇˇ ⁄| ( Ñ 1
° d ONLN d ö ä • ê ( ¢ äY @Ä ° d ONLN d ö ê •H )(our application can use Device Manager r \` ° d ONLN d B öH • )∏,outines to communicate with devices. It can ° d ONLN d n ¶ ä ± ∏ ( Æ ä use these r 6¿ ° d ONLN d y ¶ π ± )/Moutines to open and close device drivers, to exchange information with them, ° d ONLN d Δ ≤ ä Ω Ì ( ∫ äand to otherwise contr Ô ° d ONLN d ‹ ≤ Ì ΩJ )col and monitor them. ° d ONLN d Ò ƒ ä œÂ ( à äNThe Device Manager includes high-level and low-level versions of most of its r e† ° d ONLN d? ƒÂ œ
( ÃÂ outines. ° d ONLN dH – ä € ¸ ( ÿ äThe high-level versions ar ‡ ° d ONLN db – ˝ €€ )s3e somewhat easier to use, but they allow less contr ø† ° d ONLN dï –€ € )fi
ol of how ° d ONLN dü ‹ ä Á! ( ‰ ä!the Device Manager executes the r ›` ° d ONLN d¿ ‹! Áÿ )ó)outine (for example, they always execute ° d ONLN dÈ Ë ä Û ß ( äsynchr $ ° d ONLN dÔ Ë ® Û ˛ ) onously) and they r é† ° d ONLN d Ë ˛ ÛÌ )V6eturn less information to your application. Conversely ] ° d ONLN d8 ËÌ Û )Ô, the ° d ONLN d> Ù ä ˇ π ( ¸ ä low-level r ÿ ° d ONLN dI Ù π ˇ fl )/ outines r ú` ° d ONLN dR Ù ‡ ˇ ˜ )'equir ≥† ° d ONLN dW Ù ˜ ˇƒ ).e some additional setup, but they allow you gr T@ ° d ONLN dÖ Ù≈ ˇÙ )Œ eater contr [ ° d ONLN dê ÙÙ ˇ )/ol and ° d ONLN dó ä ç ( är E ° d ONLN dò é ∫ ) eturn mor ™† ° d ONLN d° ∫ ¯ ),e information. ° d ONLN d∞ ä – ( äThe high-level r y ° d ONLN d¿ – ˇ )F outines dif ¢‡ ° d ONLN dÀ ˇ Ñ )/ fer in form, but the low-level r @ ° d ONLN dÎÖ ı )Üoutines all have the form: ,
Courier . ° d ONLN d) ä5 ¿ (2 ä FUNCTION ° d ONLN d) ¿5 )6
PBRoutineName ° d ONLN d&)5™ )N (paramBlock: ParmBlkPtr; ° d ONLN dL7C§ + async: Boolean): OSErr; ° d ONLN ddP ä[ ¶ (X äThe fi ° d ONLN djP ¶[ Ë ) rst parameter ° d ONLN dxO Ë[$ )B
e to pass mor h ° d ONLN d›\6g );2e complete information to the driver than you can ° d ONLN dh äs ” (p äwith high-level r Ä ° d ONLN d h ‘sõ )J.outines, and the driver uses the same data str ÚÄ ° d ONLN dNhõs≤ )«uctur x` ° d ONLN dSh≥s )e to pass information ° d ONLN dit ä (| äback. The section “Data Str ㆠ° d ONLN dÑt )wuctur Ä ° d ONLN dât9 )es,” on fl ° d ONLN dët9Y ) page 1-
¿ ° d ONLN dòtZd )!14
¿ ° d ONLN dötd´ )
, discusses the fi 1 ° d ONLN d¨t´ )Gelds of the parameter ° d ONLN d¬Ä äã À (à äblock in detail. ˇ˛ˇ˛ . ° d ONLN d”í äù Ó *The second parameter ˇ˝ˇ¸ ˙ ° d ONLN dËë Ôù
. In this ˇˇÕ . ° d ONLN dıÏ ä˜ ™ (Ù äcase, a ˇ˛1ö ±ö ° d ONLN d˝Î ™˜ » ) noErr ˇˇÕ ±ö ° d ONLN dÏ »˜ Œ ) r ú« ° d ONLN dÏ Œ˜ )esult code signifi Œa ° d ONLN dϘQ )K
es that the r Î( ° d ONLN d#ÏQ˜ )8-equest was successfully queued, not that the . ° d ONLN dP¯ ä ç ( är E ° d ONLN dQ¯ é, )#equest was successfully completed. ó ° d ONLN dt¯,2 )ûY WÄ ° d ONLN du¯2 )2our application can determine when the driver has . ° d ONLN dß ä ” ( äcompleted the r R` ° d ONLN d∂ ”t )I#equest by periodically polling the R` ° d ONLN dŸt§ )°ioResult R` ° d ONLN d·§Æ )0 fi R` ° d ONLN d‰Æ )
eld of the parameter . ° d ONLN d˘ ä0 ( ä%block. The Device Manager sets this fi M‡ ° d ONLN d 1É )ßeld to 1 when the r π@ ° d ONLN d2É )R!equest is queued, and the driver ° d ONLN dS ä' ö ($ ästor 9‡ ° d ONLN dW õ' ◊ )es the actual r ° d ONLN df ÿ' )=esult code ther ´ ° d ONLN du 'Ü )@e when it completes the r < ° d ONLN dé á'¶ )oequest. ˇˇËZ . ° d ONLN dñ. ä9 ë (6 äY ï ° d ONLN dó. ê9 Œ )ou can also pr n ° d ONLN d•. œ9- )?ovide a pointer to a ˇˇÏK . ™0 ° d ONLN d∫.-9Ñ )^completion routine ˇˇËZ .
ª ° d ONLN dÃ.Ö9¶ )X in the ˇˇ–¥ Δ… ° d ONLN d‘-¶9Ó )! ioCompletion ˇˇËZ Δ… ° d ONLN d‡.Ó9˜ )H fi Ø# ° d ONLN d„.¯9 )
eld of . ° d ONLN dÍ: äEÑ (B ä7the parameter block. The Device Manager executes this r j¿ ° d ONLN d !:ÑEÏ )˙outine when the driver ° d ONLN d 8F äQ Ï (N äcompletes the asynchr ∏` ° d ONLN d MF ÏQ
)bonous r ˝‡ ° d ONLN d TF
Q. )!equest.
° d ONLN d ]_ äi ∞ (f äASSEMBL Û ° d ONLN d d_ ∞i µ )&Y €7 ° d ONLN d e_ µi ˝ )-LANGUAGE NOTE
° d ONLN d tj äu ê (r äY @Ä ° d ONLN d uj êu ) ou can call a Device Manager r Ê ° d ONLN d ìjuX )áoutine asynchr L† ° d ONLN d °jYu| )Bonously ®‡ ° d ONLN d ®j{uø )", bypassing the ° d ONLN d ∏v äÅ ç (~ är E ° d ONLN d πv éÅ™ )Bequest queue, by setting the immediate bit (bit 9) of the trap wor `‡ ° d ONLN d ˚v™Åµ (~™d. ° d ONLN d ˛Ç äç ≥ (ä äHowever † ° d ONLN d
Ç ≥ç ª )), r —† ° d ONLN d
Ç ªçç )-emember that the driver might have an asynchr sÄ ° d ONLN d
5Çéç´ )”onous ° d ONLN d
;é äô ç (ñ är E ° d ONLN d
<é éôr )3equest pending. In fact, if you make an immediate r %@ ° d ONLN d
oérô≤ )‰equest during ° d ONLN d
}ö ä• ¢ (¢ äinterr ° d ONLN d
Éö £•7 )"upt time, the driver might be curr ¡ ° d ONLN d
•ö7•° )îently executing another ° d ONLN d
Ω¶ ä± ç (Æ är E ° d ONLN d
æ¶ é± À )equest. Be sur f` ° d ONLN d
ö À± )=e the driver is r Q ° d ONLN d
›¶±´ )C%eentrant—that is, that it can handle ° d ONLN d ≤ äΩ — (∫ äthese situations. ,
ˇˇ◊ ˇ◊ ° d ONLN d ] l mk ( i l"Opening and Closing Device Drivers ˇˇˇˇˇˇ • ( i1
° d ONLN d # t l r ( | lY @Ä ° d ONLN d $ t r Ì )ou must open a driver befor „ ° d ONLN d ? t Ì Ê ){7e your application can communicate with it. The Device . ° d ONLN d v Ä l ã ° ( à l
Manager pr R` ° d ONLN d Ä Ä ° ã — )5
ovides thr $¿ ° d ONLN d ä Ä — ãá )0)ee functions for opening device drivers: ,
° d ONLN d÷ Ÿ l ‰î * BThe initial period in a driver name allows the Device Manager and ˇ˛ú⁄ . ° d ONLN d  l ∫ * the File Manager ¸T ° d ONLN d(  π )M, which both use the ˇ˝9¥ ñ ° d ONLN d= ‰ : )]PBOpen ˇ˛ú⁄ ñ ° d ONLN dC Â: § )$ function, to distinguish . ° d ONLN d] Ò l ¸ ( ˘ l!between device driver names and fi ¸@ ° d ONLN d Ò ¸s )ùle names. For the same r ŒÄ ° d ONLN dó Òt ¸í )keason, ° d ONLN dû ˝ l r ( lfi å¿ ° d ONLN d† ˝ r π )lenames should y‡ ° d ONLN dØ ˝ ∫ « )Hnot Õ ° d ONLN d≤ ˝ « )
start with a period. ,
Zapf Dingbats
å† ° d ONLN dˇˇ )]u
° d ONLN d› l` ( l5The Device Manager assigns each open device driver a ¬ ° d ONLN d`œ )Ùdriver reference number L¿ ° d ONLN d)œ— )o. ÿ ° d ONLN d*—È ) This ° d ONLN d0 l&_ (# l5number allows the Device Manager to locate the driver è` ° d ONLN de`&ü )Ù’s device contr ° d ONLN dt†&Ù )@ol entry in the unit ° d ONLN dâ' l2 É (/ ltable. ˇˇÓx . ° d ONLN dê9 lD Ä *The ˇˇ‹ nx ° d ONLN dî8 ÅD Ω )
OpenDriver ˇˇÓx nx ° d ONLN dû9 ΩDá )<, function, which is the high-level opening r Δ ° d ONLN d 9áD˜ ) outine, takes the driver . ° d ONLN d„E lP • (M l
name as its fi Ä ° d ONLN dÒE ¶P ˚ ):rst parameter and r U† ° d ONLN dE ˚PK )Ueturns the driver r Â` ° d ONLN dEKP[ )Pefer ëÄ ° d ONLN dE\P— )ence number in its second ° d ONLN d5Q l\ ô (Y l parameter S† ° d ONLN d>Q ô\ õ )-. ˇˇàç . ° d ONLN d@c ln õ (k l Listing 1-1 ç ° d ONLN dKc ún )0 shows how to use the ˇˇ ;€ ° d ONLN dabn> )f
OpenDriver ˇˇàç ;€ ° d ONLN dkc>n∫ )< function to open a driver fr Aâ ° d ONLN dàc∫n÷ )|om a r % ° d ONLN déc÷nÌ ) esour ˜c ° d ONLN dìcÏn˜ )ce . ° d ONLN dño lz r (w lfi å¿ ° d ONLN dòo rz | )le.
ù *†¯ 4ù *†¯ "ù *a
ˇ·ˇ‚7^
° d ONLN dˇˇ (ö l Listing 1-1 ° d ONLN dúí ∞ùW )D)Opening a device driver from a resource fi ° d ONLN dΔíXù_ )®le
. ° d ONLN d…™ l∂ Ñ (≥ lVAR ° d ONLN dŒ™ Ñ∂ Δ ) gDrvrRefNum ° d ONLN d‹™ Δ∂ )B
: Integer; ° d ONLN dÁƒ l– ˆ (Õ lPROCEDURE MyOpenDriver; ° d ONLN d“ ~fi ê +VAR ° d ONLN d ‡ êÏ ∫ +drvrHdl ° d ONLN d‡ ∫Ï )* : Handle; ° d ONLN d$Ó ê˙ ¥ (˜ êdrvrID ° d ONLN d,Ó ¥˙ )$
. ° d ONLN d \ Æ hŒ ( e Æ0GetResInfo(drvrHdl, drvrID, drvrType, drvrName); ° d ONLN d 6 j Æ v™ **SetResInfo(drvrHdl, tempDrvrID, drvrName); ° d ONLN d h Ü Æ í§ * )err := OpenDriver('.DRIVER',gDrvrRefNum); ° d ONLN d ô ¢ Æ Æ, * IF (err = NoErr) THEN ° d ONLN d µ ∞ ¿ ºP +DetachResource(drvrHdl); ° d ONLN d ÷ Ã Æ ÿº ( ’ Æ-drvrHdl := GetNamedResource('DRVR',drvrName); ° d ONLN d ⁄ Æ Êå *%SetResInfo(drvrHdl,drvrID, drvrName); ° d ONLN d3 Ë ú Ù ¥ ( Ò úEND; ° d ONLN d8 ä ü ( äThe ° d ONLN d< ü € )
OpenDriver ° d ONLN dF € 1 )< function uses the r R` ° d ONLN dZ1 H )Vesour $¿ ° d ONLN d_H ¶ )ce ID of the driver r ˜ ° d ONLN dt• º )]esour …Ä ° d ONLN dyº )ce to determine . ° d ONLN dâ
ä † ( äwher 7 ° d ONLN dç
° )e in the unit table to stor à¿ ° d ONLN d®
Y )ke the device contr ° d ONLN d∫
Zπ )Nol entry for the driver ` ° d ONLN d—
π¸ )_. Unfortunately † ° d ONLN d‡
˚ )B, the . ° d ONLN dÊ ä$ Δ (! ä
OpenDriver ° d ONLN d Δ$ª )<7 function does not check to see if another device contr R` ° d ONLN d'ª$˚ )ıol entry is alr $¿ ° d ONLN d6˚$ )@eady . ° d ONLN d;% ä0: (- ä+located in that position in the unit table. ˇˇÊß . ° d ONLN dg7 äB † *Ther R` ° d ONLN dk7 †B ≤ )efor $¿ ° d ONLN do7 ≤B œ )e, the ˇˇÕN Ú ° d ONLN dv6 œB ) MyOpenDriver ˇˇÊß Ú ° d ONLN dÇ7B# )H pr ´ ° d ONLN dÖ7$BA )
ocedur }u ° d ONLN dã7AB| )
e begins by fi 1j ° d ONLN dô7}B )<!nding an empty space in the unit . ° d ONLN d∫C äN (K ä table and then changes the r c ° d ONLN d÷CN )|esour ´@ ° d ONLN d€C Nt )ce ID of the driver r E‡ ° d ONLN dCuNç )Wesour é ° d ONLN dıCçNØ )ce befor '† ° d ONLN d˝C∞NÁ )#e calling the . ° d ONLN d N äZ Δ (W ä
OpenDriver ° d ONLN dO ΔZC )< function. (The chapter “W ¬† ° d ONLN d/OBZ_ )|riting ï ° d ONLN d6O_Zf ) Y ™ ° d ONLN d7OeZ¸ ) our Own Device Driver” gives a ° d ONLN dV[ äf » (c ä complete defi ° d ONLN dc[ »f )>nition of the ° d ONLN dqZfõ )=FindEmptySpaceInUnitTable ° d ONLN dä[õf… )ñ function.) ° d ONLN dñm äx (u ä After the driver is open, the ° d ONLN d¥lxZ )à MyOpenDriver ° d ONLN d¿mZxg )H pr R` ° d ONLN d√mgxÑ )
ocedur $¿ ° d ONLN d…mÑxœ ) e detaches the r ˜ ° d ONLN dŸmŒx )Jesour …Ä ° d ONLN dfimÂx )ce and . ° d ONLN dÂy äÑ ç (Å är E ° d ONLN dÊy éÑ £ )estor »Ä ° d ONLN dÎy £Ñ Á )es the original r s@ ° d ONLN d¸y ËÑ )Eesour ªÄ ° d ONLN dy Ñ )ce ID. . ° d ONLN dã äñ ü (ì äThe ° d ONLN d ä üñ √ )PBOpen ° d ONLN dã √ñ ⁄ )$ and ° d ONLN dä ⁄ñ
)OpenSlot ° d ONLN d ã
ñf )0 functions, which ar R` ° d ONLN d3ãfñ )\&e low-level functions, use the Device . ° d ONLN dYó 䢰 (ü ä>Manager parameter block, which is described fully in “Data Str Ø@ ° d ONLN dóó°¢∏ (ü°uctur 5 ° d ONLN dúóπ¢◊ )es” on dž ° d ONLN d£ó◊¢˜ ) page 1- ±` ° d ONLN d™ó˜¢ ) 14 ±` ° d ONLN d¨ó¢ )
. ˇ˛ñï . ° d ONLN dÆ£ äÆ™ (´ äCBoth of these functions expect a pointer to the driver name in the ˇ˝-* %ë ° d ONLN dÒ¢´Æ· (´´ ioNamePtr ˇ˛ñï %ë ° d ONLN d˙£·ÆÈ )6 fi º& ° d ONLN d˝£ÈÆ ) eld of the ° d ONLN dØ ä∫ (∑ äparameter block and r R` ° d ONLN d Ø ∫! )f eturn the r $¿ ° d ONLN d(Ø!∫3 )1efer ˜ ° d ONLN d,Ø2∫ä )ence number in the ˜ ° d ONLN d?Æä∫∫ )XioRefNum ˜ ° d ONLN dGØ∫∫ƒ )0 fi ˜ ° d ONLN dJ؃∫Ÿ )
eld. ˇˇ{é ° d ONLN dP¡ äà ë (… äY ï ° d ONLN dQ¡ êà ø ) ou use the ˇ˛˜ ™ ° d ONLN d\¿ ¿Ã ‰ )0PBOpen ˇˇ{é ™ ° d ONLN db¡ ‰Ã ˘ )$ and ˇ˛˜ ˛Δ ° d ONLN dg¿ ˘Ã) )OpenSlot ˇˇ{é ˛Δ ° d ONLN do¡)Ãk )0 functions in pr C– ° d ONLN d¡lÃ~ )Cefer 0 ° d ONLN dÉ¡~ñ ) ence to the ˇ˛˜ à⁄ ° d ONLN d迱ÃÌ )3
OpenDriver ˇˇ{é à⁄ ° d ONLN dô¡Ìà )<
function . ° d ONLN d£Õ äÿ „ (’ äwhen you want mor H` ° d ONLN d¥Õ ‰ÿ )Ze contr PÄ ° d ONLN dªÕÿ¸ ) 6ol over how the Device Manager opens the device driver Ÿ¿ ° d ONLN dÒÕ˚ÿ )˘. For . ° d ONLN d˜Ÿ ä‰ (· äexample, you can set r R` ° d ONLN d
Ÿ ‰› )f2ead and write permissions for the device with the R` ° d ONLN d?ÿ›‰ )Ì ioPermssn R` ° d ONLN dHŸ‰ )6 . ° d ONLN dI ä ê (Ì äfi å¿ ° d ONLN dK ê )eld of the parameter block. . ° d ONLN dg˜ ä ë (ˇ äY ï ° d ONLN dh˜ ê ¡ ) ou use the ï ° d ONLN dsˆ ¡ Ò )1OpenSlot ï ° d ONLN d{˜ Ò )0A function to open drivers that serve slot devices. This function . ° d ONLN dº ä} ( ä6uses an extended parameter block that includes extra fi ®¿ ° d ONLN dÛ}≠ )Û elds specifi °† ° d ONLN dˇÆÒ )1c to slot device . ° d ONLN d ä ± ( ä drivers. R` ° d ONLN d ± ∏ )'Y g` ° d ONLN d ∑ Ë ) ou use the g` ° d ONLN d% Ë )1PBOpen g` ° d ONLN d+ œ )$+ function to open any other device drivers. . ° d ONLN dW! ä, ê () äY @Ä ° d ONLN dX! ê,. )"ou must open device drivers synchr íÄ ° d ONLN dz!.,Q )ûonously Ó¿ ° d ONLN dÅ!P,∏ )". If a device driver is alr ˚ ° d ONLN dú!∏,˚ )heady open, the ° d ONLN d´- ä8 • (5 ädriver ´† ° d ONLN d±- •8 ” )
-opening r † ° d ONLN dª- ”8 ).outines simply r W` ° d ONLN dÀ-8g )Heturn the driver r ™ ° d ONLN d›-g8w )Lefer V@ ° d ONLN d·-x8± ) ence number fi ° d ONLN dÏ-∞8≤ )8. ° d ONLN dÓ? äJ ° (G äThe r Ä¿ ° d ONLN dÛ? °J )emaining Device Manager r G` ° d ONLN d ? JB ){ outines r ¿ ° d ONLN d?CJZ )'equir # ° d ONLN d?ZJfi ) e your application to use the r ‡ ° d ONLN d9?fiJÓ )Ñefer ∂ ° d ONLN d=?ÓJ )ence ° d ONLN dBK äV ¨ (S änumber ≥ ° d ONLN dHK ¨VI )"$, instead of the driver name, when r H‡ ° d ONLN dlKJV° )ûeferring to a device. ° d ONLN dÇ] äh √ (e ä When you ar Ω ° d ONLN dç] √h )9e done using a driver €‡ ° d ONLN d¢] hø )]#, you may want to close it. However yÄ ° d ONLN d≈]øh¯ )ü
, you should ° d ONLN d“i ät (q äYgenerally not close drivers that might be needed by the system or by other applications. ° d ONLN d +u äÄ¥ * BWhether you should close a particular driver depends on the driver ¡ ° d ONLN d mu¥Äπ (}¥. ìÄ ° d ONLN d ouπÄø )Y T ° d ONLN d puøÄ )ou should check ° d ONLN d ÄÅ äåB (â ä*the documentation for the driver if you ar † ° d ONLN d ™ÅCåi )π e not sur d† ° d ONLN d ≥Åiå¬ )&e. Other chapters in ì@ ° d ONLN d »Å¬å )YInside Macintosh u@ ° d ONLN d ÿÅå
)F ° d ONLN d Ÿç äò* (ï ä%give this information for the standar ¶¿ ° d ONLN d ˛ç*òÖ )†d Macintosh drivers. ˇ ‰ @ ˇ ˇˇˇˇ @
ˇˇ˚‘ . ° d ONLN d ] l h ¸ ( e l If you do want to close a driver •l ° d ONLN d ] ¸ h )ê , you can use the high-level ,
Courier ˇˇ˜® åd ° d ONLN d = \Ä h¬ )Ñ CloseDriver ˇˇ˚‘ åd ° d ONLN d H ]¬ h˜ )B
function or ˇˇíG ° d ONLN d U i l t ≠ ( q lthe low-level ˇˇ$é §é ° d ONLN d c h ≠ t ◊ )APBClose ˇˇíG §é ° d ONLN d j i ◊ t )* function. … ° d ONLN d u i t2 ), Listing 1-2 [c ° d ONLN d Ä i3 tô )0 shows how to use the ˇˇ$é …
° d ONLN d ñ hô t√ )fPBCLose ˇˇíG …
° d ONLN d ù i√ t˜ )*
function to . ° d ONLN d ™ u l Ä · ( } lclose the driver opened in Ω ° d ONLN d ≈ u · Ä )u Listing 1-1 ]` ° d ONLN d – u Ä )/.
¢ * ¶¯ 4 £ * •¯ " £ *a
ˇ·ˇ‚7^
° d ONLN dˇˇ ( † l Listing 1-2 ° d ONLN d “ ò ∞ £ )DClosing a device driver
. ° d ONLN d Í Ø l ª ¸ ( ∏ lPROCEDURE MyCloseDriver; ° d ONLN d Ω ~ … ê +VAR ° d ONLN d À ê ◊ Ã +
paramBlock ° d ONLN d À à ◊, )<: ParamBlockRec; ° d ONLN d1 Ÿ ê  ¢ ( ‚ êerr ° d ONLN d7 Ÿ Δ Â ˆ )6: OSErr; ° d ONLN dE ı ~ ú ( ˛ ~BEGIN ° d ONLN dP ê +paramBlock.ioCompletion ° d ONLN dhD )ä:= nil; ° d ONLN du ê ( êparamBlock.ioRefNum ° d ONLN dä \ )r:= gDrvrRefNum; ° d ONLN d°- ê9h (6 ê$err := PBClose (@paramBlock, FALSE); ° d ONLN d ; ~G ñ (D ~END; ° d ONLN dœT l_ Å (\ lThe ° d ONLN d”S Å_ œ )
MyCloseDriver ° d ONLN d‡T œ_ ‹ )N pr R` ° d ONLN d„T ‹_ ˘ )
ocedur $¿ ° d ONLN dÈT ˘_ ) e specifi $¿ ° d ONLN dÚT _õ )& es the driver to close by pr ˜ ° d ONLN dTö_Û ){oviding the driver ˇˇÜÉ ° d ONLN d!` lk p (h lr R` ° d ONLN d"` pk Ç )efer $¿ ° d ONLN d&` Çk ÿ )ence number in the ˇˇ
>à ° d ONLN d9_ ÿk )VioRefNum ˇˇÜÉ >à ° d ONLN dA`k )0 fi ≈O ° d ONLN dD`k˜ ) 2eld of the parameter block and indicates that the ° d ONLN dvl lwS (t l0Device Manager should not execute a completion r R` ° d ONLN d¶lSw≤ )Áoutine by specifying R` ° d ONLN dªk≤wƒ )_NIL Ù ° d ONLN dæl√w ) in the ° d ONLN dΔw lÉ ¥ (Ä l ioCompletion ° d ONLN d“x ¥É ª )H f PÄ ° d ONLN d‘x ªÉA ) ield of the parameter block.
ˇˇ◊ . ˇ◊ ° d ONLN dÚò l® (§ lCommunicating W Üù ° d ONLN dò ®m )Ñith Device Drivers ˇˇˇˇˇˇ • (§1
° d ONLN dØ l∫ (∑ l(Once a driver is open and you have its r fl@ ° d ONLN d<Ø ∫, )∞efer ã` ° d ONLN d@Ø-∫f ) ence number @ ° d ONLN dKØf∫Ï )9 , you can use Device Manager ° d ONLN dhª lΔ ∑ (√ lcommunication r ıÄ ° d ONLN dwª ∑Δg )K(outines to exchange information with it. ° d ONLN d†Õ lÿ\ (’ l4When you want to send information to a device driver KÄ ° d ONLN d‘Õ\ÿz ), you fi ‰ ° d ONLN d‹Õzÿò ) rst stor è‡ ° d ONLN d‰ÕôÿÛ ) e the information in ˇˇæΔ . ° d ONLN d˘Ÿ l‰ õ (· l
a data buf œÏ ° d ONLN dŸ õ‰ ˝ )/fer and then call the ˇˇ}å â ° d ONLN dÿ ˛‰( )cFSWrite ˇˇæΔ â ° d ONLN d Ÿ(‰o )* function or the ˇˇ}å Ñ‚ ° d ONLN d1ÿp‰ö )HPBWrite ˇˇæΔ Ñ‚ ° d ONLN d8Ÿö‰˜ )* function. When you . ° d ONLN dL l î (Ì l want to r g† ° d ONLN dU î )(eceive information fr ó† ° d ONLN dj B )\om a device driver ™‡ ° d ONLN d|ÂB` )R, you fi C` ° d ONLN dÑÂaø ) rst allocate a data buf ã ° d ONLN dõÂøÔ )^ fer to hold . ° d ONLN dßÒ l¸ (˘ l#the information, and then call the ° d ONLN d ¸3 )£FSRead ° d ONLN d–Ò3¸B )$ or ° d ONLN d‘B¸f )PBRead ° d ONLN d⁄Òf¸ì )$ function. R` ° d ONLN dÂÒì¸ö )-Y g` ° d ONLN dÊÒô¸ı )ou must specify the . ° d ONLN d˙˝ l ( l"number of bytes you want transferr ®Ä ° d ONLN d ˝ µ )ù'ed when calling any of these functions. ˇ˛ß“ . ° d ONLN dD l √ ( lLike all low-level r I÷ ° d ONLN dX ƒ ˙ )X
outines, the ˇ˝O§ ôz ° d ONLN de ˙$ )6PBWrite ˇ˛ß“ ôz ° d ONLN dl$8 )* and ˇ˝O§ È ° d ONLN dq8\ )PBRead ˇ˛ß“ È ° d ONLN dw\˜ )$% functions allow you to transfer the . ° d ONLN dú l& Δ (# linformation asynchr _Ä ° d ONLN dØ Δ& È )Zonously ª¿ ° d ONLN d∂ Ë&ã )"%, and with these functions you can pr ?¿ ° d ONLN d€å&„ )§ovide a completion ° d ONLN dÓ' l2 o (/ lr E ° d ONLN dÔ' p2ç )@outine. These functions also allow you to specify a drive number Ó¿ ° d ONLN d/'å2Î (/å, a positioning mode, ˇ˛»l . ° d ONLN dE3 l> ƒ (; land a positioning of ´§ ° d ONLN dY3 ƒ> Û )X fset in the ˇ˝êÿ Ë ° d ONLN de2 Ù>* )0 ioVRefNum ˇ˛»l Ë ° d ONLN dn3*>. )6, ˇ˝êÿ ÕT ° d ONLN dp2.>d ) ioPosMode ˇ˛»l ÕT ° d ONLN dy3d>{ )6, and ˇ˝êÿ ^, ° d ONLN d2|>æ ) ioPosOffset ˇ˛»l ^, ° d ONLN dä3æ>Δ )B fi &ò ° d ONLN dç3«>¯ ) elds of the . ° d ONLN dô? lJfi (G lPparameter block. The Device Manager uses the positioning mode and positioning of !‡ ° d ONLN dÈ?flJÒ (Gflfset ° d ONLN dÓK lV Ω (S lto determine wher *@ ° d ONLN dˇK æVu )R+e on a block device the transfer will occur †‡ ° d ONLN d*KtV◊ )∂. The Device Manager ° d ONLN d?W lb= (_ l.simply passes the drive number onto the driver ¢ ° d ONLN dmW=b] )—. Be sur † ° d ONLN duW^b )! e you specify these values in a ° d ONLN dïc ln4 (k l,manner compatible with the particular driver ëÄ ° d ONLN d¡c4n6 )». ° d ONLN d√u lÄ € (} lThe Device Manager defi è@ ° d ONLN d⁄u €Ä ˘ )ones thr ¿ ° d ONLN d·u ˘Ä¶ ) 'ee positioning modes for block devices: ,
Zapf Dingbats
° d ONLN d â lê q (è ln
° d ONLN d á xí ® ) At the curr ñ ° d ONLN dá ®í Î )0ent position. W u` ° d ONLN d%á Îí¨ )C.ith this mode, the transfer begins at the curr ∞@ ° d ONLN dSá¨í )¡ent position on ° d ONLN dcì xû ˜ (õ xthe medium—typically wher ` ° d ONLN d|ì ¯ûd )Äe the last transfer ended.
° d ONLN dóß lÆ q (≠ ln
° d ONLN dô• x∞ É ) Of Ç ° d ONLN dõ• É∞ ú ) fset fr ∑‡ ° d ONLN d¢• ú∞O )(om the start. This mode allows you to pr æÄ ° d ONLN d •O∞Ø )≥ovide a positioning of @ ° d ONLN d‡•∞∞‚ )a fset, which ° d ONLN dϱ xº î (π xspecifi Ó ° d ONLN dÛ± îº ˝ ) es at how many bytes fr ° d ONLN d
± ˛ºı )j7om the beginning of the medium the transfer will begin. ˇ( @ ˇ ˇˇˇˇ @
° d ONLN d ] ñ h ° ) Of Ç ° d ONLN d ] ° h ∫ ) fset fr ∑‡ ° d ONLN d ] ∫ h )om the mark. W ߇ ° d ONLN d ] hm )Gith this mode you can pr †Ä ° d ONLN d 1 ]m hÕ )lovide a positioning of ˝@ ° d ONLN d G ]Õ hÚ )`
fset that ° d ONLN d Q i ñ t ≤ ( q ñspecifi Ó ° d ONLN d X i ≤ t ) es at how many bytes fr ° d ONLN d o i tO )j om the curr X ° d ONLN d z iO tÏ )3&ent position the transfer will begin. . ° d ONLN d ° { ä Ü Â ( É äOn completion, the ,
Courier ° d ONLN d ¥ z Â Ü )[PBRead ° d ONLN d ∫ { Ü )$ and ° d ONLN d ø z ÜJ )PBWrite ° d ONLN d Δ {J Ü| )* functions r R` ° d ONLN d “ {| Ü
)2 eturn the total number of bytes ˇ˛»l ° d ONLN d Ú á ä í ⁄ ( è äactually transferr à ° d ONLN d á € í )Q
ed in the ˇ˝êÿ t ° d ONLN d Ü í@ ))
ioActCount ˇ˛»l t ° d ONLN d á@ íH )< fi <| ° d ONLN d áI í ) /eld of the parameter block. For block devices, ° d ONLN dJ ì ä û Î ( õ äthese functions also r R` ° d ONLN d` ì Î ûb )aeturn a new positioning of $¿ ° d ONLN dz ìb ûï )w fset in the $¿ ° d ONLN dÜ íï û◊ )3 ioPosOffset $¿ ° d ONLN dë ì◊ û· )B fi $¿ ° d ONLN dî ì· ûÛ )
eld. . ° d ONLN dô • ä ∞ ¯ ( ≠ äCertain device drivers pr ⁄† ° d ONLN d≤ • ¯ ∞ì )n%ovide additional abilities with the r %† ° d ONLN d◊ •î ∞Î )úeading and writing ˇˇ . ° d ONLN dÍ ± ä ºü ( π ä>functions. For example, the Disk Driver allows you to use the ˇ˛"" ;ª ° d ONLN d( ∞† ºƒ ( π†PBRead ˇˇ ;ª ° d ONLN d. ±ƒ º )$ function to verify . ° d ONLN dB Ω ä »† ( ≈ ä>that data written to a block device matches the data in memory Ò† ° d ONLN dÄ Ωü »™ ( ≈ü. T '` ° d ONLN dÉ Ω™ » ) o do this, you add the ° d ONLN dö … ä ‘ ç ( — är E ° d ONLN dõ … é ‘ „ )ead-verify constant . ° d ONLN dØ ‡ ä Ï ( È äCONST rdVerify = 64; ˇˇàá ° d ONLN dƒ ˘ ä ® *to the ˇˇ ë ° d ONLN dÀ ¯ ® fi ) ioPosMode ˇˇàá ë ° d ONLN d‘ ˘ fi Á )6 fi ï ° d ONLN d◊ ˘ Ë )
Celd of the parameter block, as explained in the description of the ° d ONLN d ä Æ (
äPBRead ° d ONLN d Æ( )$ function in “Routines,” on ° d ONLN d<(I )zpage 1- ° d ONLN dCIS )!25 ° d ONLN dESV )
. . ° d ONLN dG ä" ∏ ( ä Listing 1-3 @ ° d ONLN dR π"„ )/A shows an example that exchanges information with a device driver Õ@ ° d ONLN dì‚"Á ( ‚.
D HH 4E HG "E Ha
ˇ·ˇ‚7^
° d ONLN dˇˇ (B ä Listing 1-3 ° d ONLN dñ: ŒE\ )D"Communicating with a device driver
. ° d ONLN dºQ ä], (Z äPROCEDURE MyReadFromDriver; ° d ONLN d‹_ úk Æ +VAR ° d ONLN dÂm Æy Í +
paramBlock ° d ONLN dm ÍyJ )<: ParamBlockRec; ° d ONLN d{ Æá ¿ (Ñ Æerr ° d ONLN d { ‰á )6: OSErr; ° d ONLN dâ Æï ÿ (í ÆreadBuf ° d ONLN d#â ÿï )* : Str255; ° d ONLN d2• ú± ∫ (Æ úBEGIN ° d ONLN d=≥ Æø8 +paramBlock.ioCompletion ° d ONLN dU≥8øb )ä:= nil; ° d ONLN db¡ ÆÕ ( ÆparamBlock.ioRefNum ° d ONLN dw¡ Õz )r:= gDrvrRefNum; ° d ONLN dåœ Æ€ (ÿ ÆparamBlock.ioBuffer ° d ONLN d°œ €h )r := @readBuf; ° d ONLN d≥› ÆÈ, (Ê ÆparamBlock.ioReqCount ° d ONLN d…›,ÈV )~:= 256; ° d ONLN dÿ˘ ÆÄ ( Æ#err := PBRead (@paramBlock, FALSE); ° d ONLN d ú ¥ ( úEND; ° d ONLN d# ä/& (, äPROCEDURE MyWriteToDriver; ° d ONLN d%1 ú= Æ +VAR ° d ONLN d.? ÆK Í +
paramBlock ° d ONLN d9? ÍKJ )<: ParamBlockRec; ° d ONLN dOM ÆY ¿ (V Æerr ° d ONLN dUM ‰Y )6: OSErr; ° d ONLN dc[ Æg “ (d Æbuffer ° d ONLN dk[ “g )$ : Str255; ˇ ¬ @ ˇ ˇˇˇˇ @
. ° d ONLN d j ~ v ú ( s ~BEGIN ° d ONLN d x ê Ñ, +buffer := 'Data to Write'; ° d ONLN d , î ê † * paramBlock.ioCompletion ° d ONLN d D î †D )ä:= nil; ° d ONLN d Q ¢ ê Æ ( ´ êparamBlock.ioRefNum ° d ONLN d f ¢ Æ\ )r:= gDrvrRefNum; ° d ONLN d { ∞ ê º ( π êparamBlock.ioBuffer ° d ONLN d ê ∞ ºD )r := @buffer; ° d ONLN d ° æ ê ( « êparamBlock.ioReqCount ° d ONLN d ∑ æ 2 )~:= 14; ° d ONLN d ≈ ⁄ ê Êh ( „ ê$err := PBWrite (@paramBlock, FALSE); ° d ONLN d Ó Ë ~ Ù ñ ( Ò ~END; ˇˇ ° d ONLN d Û l Ä ( lThe ˇ˛9‡ ú ° d ONLN d ˜ Ä ‡ )MyReadFromDriver ˇˇ ú ° d ONLN d ‡ Ï )` pr å@ ° d ONLN d
Ï ) ocedur ^† ° d ONLN d ¯ ) 6e uses a parameter block to specify the device driver . ° d ONLN dF
l Ä ( l(by r /† ° d ONLN dK
Å ë )efer €¿ ° d ONLN dO
ë< )&ence number), the number of bytes to r h† ° d ONLN du
) for the completion r Ù ° d ONLN d¡ $Ï )^1outine. It then sends the parameter block to the ˇˇíD ° d ONLN dÚ$ l0 ê (- lPBRead ˇˇ…" ° d ONLN d¯% ê0˜ )$L function. The Device Manager appends the parameter block to the end of the ˇˇ,ï ° d ONLN dD1 l< â (9 ldriver =` ° d ONLN dJ1 ä< ó ) ’s r <U ° d ONLN dN1 ó<1 )
"equest queue. Since the parameter ˇ˛Y* > ° d ONLN dp02<P )õasync ˇˇ,ï > ° d ONLN du1P<v ) is set to ˇ˛Y* Õí ° d ONLN dÄ0v<î )&FALSE ˇˇ,ï Õí ° d ONLN dÖ1î<˜ ) , the Device Manager ° d ONLN dö= lH ò (E l
does not r R` ° d ONLN d§= òH » ), eturn contr $¿ ° d ONLN dØ= »H Û )0
ol to the $¿ ° d ONLN dπ< ÛHS )+MyReadFromDriver $¿ ° d ONLN d…=SH` )` pr ˜ ° d ONLN dÃ=_H| ) ocedur …Ä ° d ONLN d“=|H‰ ) e until the driver has . ° d ONLN dÈI lT º (Q lcompleted every r ï‡ ° d ONLN d˙I ºT )Pequest in its queue. ˇˇúÓ . ° d ONLN d[ lf Ä (c lThe ˇˇ9‹ Ó ° d ONLN dZ Åf € )MyWriteToDriver ˇˇúÓ Ó ° d ONLN d"[ €f Á )Z pr å< ° d ONLN d%[ Áf ) ocedur ^ú ° d ONLN d+[f¯ ) 6e uses a parameter block to specify the device driver ˇ˛¥¯ ° d ONLN dag lr Ä (o l(by r X ° d ONLN dfg År ì )efer Ÿ∏ ° d ONLN djg ír‰ )Oence number), the size of the data to write, a pointer to the actual data, and ˇ˝i )8 ° d ONLN dπfÂr˜ (oÂNIL ˇ˛¥¯ ÿ ° d ONLN dºgˆr˜ ) ˇˇÉA ° d ONLN dΩs l~ Δ ({ lfor the completion r ‹# ° d ONLN d—s Δ~° )Z1outine. It then sends the parameter block to the ˇˇÇ yl ° d ONLN dr¢~à )‹PBWrite ˇˇÉA yl ° d ONLN d sÃ~¯ )* function. . ° d ONLN d lä≥ (á lGThe Device Manager appends the parameter block to the end of the driver q¿ ° d ONLN d[¥ä¡ (ᥒs r ª ° d ONLN d_¡ä‡ )
equest ˇˇãì . ° d ONLN dfã lñ Í (ì lqueue. Since the parameter ˇˇ& ÆL ° d ONLN dÅä Íñ )~async ˇˇãì ÆL ° d ONLN dÜãñ0 ) is set to ˇˇ& ‹ò ° d ONLN dëä0ñN )(FALSE ˇˇãì ‹ò ° d ONLN dñãNñfi ) , the Device Manager does not r Ùj ° d ONLN dµãfiñ˜ )êeturn ° d ONLN dªó l¢ Ç (ü lcontr R` ° d ONLN d¿ó Ç¢ ≠ )
ol to the R` ° d ONLN d ñ ≠¢ )+MyWriteToDriver R` ° d ONLN dŸó¢ )Z pr $¿ ° d ONLN d‹ó¢1 )
ocedur ˜ ° d ONLN d‚ó0¢Á ) 'e until the driver has completed every . ° d ONLN d £ lÆ o (´ lr E ° d ONLN d
° d ONLN dI⁄ l ø (‚ lIn addition to the r õ† ° d ONLN d]⁄ ø )Seading and writing r π@ ° d ONLN dq⁄§ )[ outines, the Device Manager pr >Ä ° d ONLN dè⁄•Â» )ãovides r ™ ° d ONLN dó⁄»ÂÍ )#outines ° d ONLN düÊ lÒ (Ó l$that allow your application to contr ° d ONLN d√Ê Òœ )ù-ol and monitor device drivers in other ways. . ° d ONLN dÒ¯ l Å ( lThe ° d ONLN dı˜ Å ´ )Control ° d ONLN d¸¯ ´ ¬ )* and ° d ONLN d˜ ¬ ¯ ) PBControl ° d ONLN d
¯ ¯∑ )6* functions allow your application to send . ° d ONLN d4¯∑Ÿ )øcontrol ° d ONLN d< l ¢ ( l information |@ ° d ONLN dG £ ” )7 to a driver P ° d ONLN dS ”@ )0. The actual type of contr ” ° d ONLN dm@— )m!ol information to which drivers r —¿ ° d ONLN dé—Û )ëespond ° d ONLN dï l í ( l varies gr ‹ ° d ONLN dû í ± )&eatly fr ¯` ° d ONLN d¶ ± ) om driver to driver n‡ ° d ONLN dπö )U!. For example, you can send contr ‡ ° d ONLN d⁄öÁ )îol information to ° d ONLN dÏ l' ù ($ l the standar ‡ ° d ONLN d˜ û' ‡ )2d Disk Driver r ‹ ° d ONLN d ‡'e )B!equesting that it eject the disk. . ° d ONLN d(. l9 Å (6 lThe ° d ONLN d,- Å9 • )Status ° d ONLN d2. •9 º )$ and ° d ONLN d7- º9 Ï )PBStatus ° d ONLN d?. Ï9¥ )0, functions allow your application to obtain . ° d ONLN dk.¥9— )»status ° d ONLN dr: lE ¢ (B l information |@ ° d ONLN d}: £E ¨ )7 fr ° d ONLN dÄ: ≠E ‡ )
om a driver ˙Ä ° d ONLN dã: flE ‰ )2. ú ° d ONLN dç: ‰Eô ))Again, the type of information drivers pr â ° d ONLN d∂:ôEÚ )µovide varies widely ° d ONLN d F lQ s (N lfr ò‡ ° d ONLN dÃF sQ » )om driver to driver ` ° d ONLN dflF »Q Õ )U. ± ° d ONLN d·F ÃQΔ )9As an example of status information, the Serial Driver pr ˜† ° d ONLN dFΔQÌ )˙ ovides a ° d ONLN d#R l] u (Z lbr Æ ° d ONLN d%R u] Ó ) eakdown of the types of err *† ° d ONLN d@R Ô]F )zors that have occurr ˚‡ ° d ONLN dTRF]W )Wed r &@ ° d ONLN dXRX]w )ecently ô@ ° d ONLN d_Rv]x ) . . ° d ONLN dad lo » (l lLike all low-level r R` ° d ONLN dud »o; )\outines, you can call the R` ° d ONLN dèc;oq )s PBControl R` ° d ONLN dòdqoà )6 and R` ° d ONLN dùcào∏ )PBStatus R` ° d ONLN d•d∏oÊ )0 functions . ° d ONLN d∞p l{ é (x lasynchr $ ° d ONLN d∑p è{ ≤ )#onously Ä` ° d ONLN dæp ±{T )"%, and with these functions you can pr ` ° d ONLN d„pU{∞ )§ovide a completion r ` ° d ONLN d˜p∞{— )[outine. ° d ONLN d Ç lçM (ä l5Because of the diversity of device drivers, the contr ° d ONLN d 5ÇNçı )‚%olling and monitoring functions have ˇˇW . ° d ONLN d Zé lô › (ñ ltwo general parameters: ˇ˛Æ Ö ° d ONLN d rç ›ô )qcsCode ˇˇW Ö ° d ONLN d xéô )$ and ˇ˛Æ 3# ° d ONLN d }çôS )
° d ONLN d ] ä h ( e ä Notice that although the contr t@ ° d ONLN d ] h )Ö*olling and monitoring functions have a dif û ° d ONLN d H ] h÷ )ªfer ÄÄ ° d ONLN d K ]÷ h ) ent interface ° d ONLN d Y i ä t ¥ ( q ä
than the r Ä ° d ONLN d c i µ t
)+Leading and writing functions, their outcome is much the same: they exchange ° d ONLN d Ø u ä Äú ( } ä<information with device drivers. Some device drivers (AppleT p¿ ° d ONLN d Î uú ÄÁ ( }úalk, for instance) ° d ONLN d ˛ Å ä å/ ( â ä#implement all communication, even r Û ° d ONLN d! Å/ åï )•eading and writing, thr §` ° d ONLN d8 Åñ å÷ )gough the contr ` ° d ONLN dF Å◊ å )A olling and ° d ONLN dQ ç ä ò Í ( ï ämonitoring functions. ° d ONLN dg ü ä ™x *4The sample device driver described in the chapter “W ˛¿ ° d ONLN dõ üw ™ë )Ìriting ∑` ° d ONLN d¢ üí ™ò )Y w‡ ° d ONLN d£ üò ™ )our Own Device Driver” ° d ONLN d∫ ´ ä ∂ √ ( ≥ ä
accepts contr Í ° d ONLN d« ´ √ ∂ )9ol and status r ° d ONLN d÷ ´ ∂' )? equests. o‡ ° d ONLN dfl ´( ∂V )& Listing 1-4 ° d ONLN dÍ ´W ∂£ )/ shows how to pr D‡ ° d ONLN d˙ ´£ ∂’ )L ovide contr l‡ ° d ONLN d ´’ ∂fl )2ol ° d ONLN d ∑ ä ¬µ ( ø äCinformation and determine status information for that device driver Å ° d ONLN dK ∑µ ¬∑ ( øµ.
‰ H Ë 4 Â H Á " Â Ha
ˇ·ˇ‚7^
° d ONLN dˇˇ ( ‚ ä Listing 1-4 ° d ONLN dM ⁄ Œ Ât )D*Controlling and monitoring a device driver ,
Courier
. ° d ONLN d{ Ò ä ˝D ( ˙ ä PROCEDURE MyIssueDriverControl; ° d ONLN dü ˇ ú Æ +VAR ° d ONLN d®
Æ Í +
paramBlock ° d ONLN d≥
ÍJ )<: ParamBlockRec; ° d ONLN d… Æ' ¿ ($ Æerr ° d ONLN dœ ‰' )6: OSErr; ° d ONLN d›7 úC ∫ (@ úBEGIN ° d ONLN dËE ÆQ8 +paramBlock.ioCompletion ° d ONLN dE8Qb )ä:= nil; ° d ONLN dS Æ_& (\ ÆparamBlock.ioCRefNum ° d ONLN d$S&_Ä )x:= gDrvrRefNum; ° d ONLN d9a Æm (j ÆparamBlock.csCode ° d ONLN dMam> )f:= 100; ° d ONLN dZo Æ{, (x ÆparamBlock.csParam[0] ° d ONLN dqo,{J )~:= 3; ° d ONLN dxoJ{™ ) { beep 3 times } ° d ONLN díã Æóí (î Æ&err := PBControl (@paramBlock, FALSE); ° d ONLN dΩô ú• ¥ (¢ úEND; ° d ONLN dΔµ ä¡2 (æ ä PROCEDURE MyGetDriverStatus; ° d ONLN dÁ√ úœ Æ +VAR ° d ONLN d— Æ› Í +
paramBlock ° d ONLN d˚— Í›J )<: ParamBlockRec; ° d ONLN dfl ÆÎ ¿ (Ë Æerr ° d ONLN dfl ‰Î )6: OSErr; ° d ONLN d%Ì Æ˘ ‰ (ˆ Æ beepTimes ° d ONLN d/Ì ‰˘ )6
: Integer; ° d ONLN d? ú ∫ ( úBEGIN ° d ONLN dJ Æ#8 +paramBlock.ioCompletion ° d ONLN db8#b )ä:= nil; ° d ONLN do% Æ1& (. ÆparamBlock.ioCRefNum ° d ONLN dÑ%&1Ä )x:= gDrvrRefNum; ° d ONLN dô3 Æ? (< ÆparamBlock.csCode ° d ONLN d¨3?> )f:= 100; ° d ONLN dªO Æ[å (X Æ%err := PBStatus (@paramBlock, FALSE); ° d ONLN dËk Æw, * IF (err = noErr) THEN ° d ONLN dy ¿Öí +#beepTimes := paramBlock.csParam[0]; ° d ONLN d,á úì ¥ (ê úEND; ˇˇ\Ô ° d ONLN d1† ä´ û (® äThe ˇ˛πfi ‹Ô ° d ONLN d5ü û´ )MyIssueDriverControl ˇˇ\Ô ‹Ô ° d ONLN dI†´" )x pr > ° d ONLN dL†#´@ )
ocedur fiû ° d ONLN dR†?´∫ ) e begins by setting up the fi 8 ° d ONLN do†ª´ )|elds of a parameter ° d ONLN dɨ ä∑ Ω (¥ ä block. The ° d ONLN dé´ Ω∑ Û )3 ioCRefNum ° d ONLN dó¨ Û∑ ˝ )6 fi ° d ONLN dö¨ ˝∑- )
eld specifi ° d ONLN d•¨-∑ë )0es the device driver r R` ° d ONLN dª¨ë∑£ )defer $¿ ° d ONLN dø¨£∑ )ence number and the ˇ® @ ˇ ˇˇˇˇ @
. ° d ONLN d \ l h ¥ ( e l ioCompletion ° d ONLN d ] ¥ h ª )H f PÄ ° d ONLN d ] ª h Ï ) ield specif ! ° d ONLN d ] Ï h ¸ )1ies ! ° d ONLN d \ ¸ h )NIL ¬† ° d ONLN d ]
hl ) for the completion r ï ° d ONLN d 5 ]l h£ )_ outine. The ï ° d ONLN d A \£ h« )7csCode ï ° d ONLN d G ]« hŒ )$ f eÄ ° d ONLN d I ]Œ h‰ )ield . ° d ONLN d N i l t à ( q lspecifi Ó ° d ONLN d U i à t ‹ ) es the type of contr ˜@ ° d ONLN d i i ‹ t )T6ol information being sent. The sample device driver fr ‡ ° d ONLN d ü i tÎ )Óom the ° d ONLN d ¶ u l Ä û ( } l
chapter “W Ö ° d ONLN d ∞ u û Ä ∏ )2riting =† ° d ONLN d ∑ u π Ä ø )Y ˛ ° d ONLN d ∏ u æ ÄL ) our Own Device Driver” interpr ;@ ° d ONLN d ÷ uM Ä≤ )èets a value of 100 as a r / ° d ONLN d Ô u≤ Ä )eequest for the ˇˇ/⁄ . ° d ONLN d ˛ Å l å ¿ ( â ldevice driver to pr ·Ó ° d ONLN d Å ¿ åà )T+oduce a system beep. When the value of the ˇ˛_¥ êò ° d ONLN d< Äâ å≠ )…csCode ˇˇ/⁄ êò ° d ONLN dB Å≠ å∂ )$ fi ¿r ° d ONLN dE Å∂ å˜ ) eld is 100, the ° d ONLN dU ç l ò ® ( ï l
value of the ° d ONLN db å ® ò “ )<csParam ° d ONLN di ç “ ò ‹ )* fi ° d ONLN dl ç ‹ ò )
eld signifi ° d ONLN dw ç òô )/ es the number of times to beep. ˇˇ∂ ° d ONLN dó ü l ™ Ä ( ß lThe ˇ˛5l ö∂ ° d ONLN dõ û Ä ™ Ê )MyGetDriverStatus ˇˇ∂ ö∂ ° d ONLN d¨ ü Ê ™ Ú )f pr áà ° d ONLN dØ ü Ú ™ ) ocedur Z, ° d ONLN dµ ü ™ù ) !e also begins by setting up the fi & ° d ONLN d◊ üû ™¯ )èelds of a parameter ° d ONLN dÎ ´ l ∂ ü ( ≥ l block. The ° d ONLN dˆ ™ ü ∂ ’ )3 ioCRefNum ° d ONLN dˇ ´ ’ ∂ fl )6 fi ° d ONLN d ´ fl ∂ )
eld specifi ° d ONLN d
´ ∂s )0es the device driver r R` ° d ONLN d# ´s ∂Ö )defer $¿ ° d ONLN d' ´Ö ∂ )ence number and the ° d ONLN d; ∂ l ¬ ¥ ( ø l ioCompletion ° d ONLN dG ∑ ¥ ¬ ª )H f PÄ ° d ONLN dI ∑ ª ¬ Ï ) ield specif ! ° d ONLN dT ∑ Ï ¬ ¸ )1ies ! ° d ONLN dX ∂ ¸ ¬ )NIL ¬† ° d ONLN d[ ∑
¬l ) for the completion r ï ° d ONLN dp ∑l ¬£ )_ outine. The ï ° d ONLN d| ∂£ ¬« )7csCode ï ° d ONLN dÇ ∑« ¬Œ )$ f eÄ ° d ONLN dÑ ∑Œ ¬‰ )ield . ° d ONLN dâ √ l Œ à ( À lspecifi Ó ° d ONLN dê √ à Œ8 ) )es the type of status information being r Ÿ ° d ONLN dπ √8 ŒÒ )∞+equested. For this particular device driver ]` ° d ONLN d‰ √Ò Œˆ )π, ° d ONLN dÊ œ l ⁄% ( ◊ l+the value 128 indicates the driver should r >† ° d ONLN d œ& ⁄Ó )∫.eturn the number of times it last beeped. The ˇˇ1fi . ° d ONLN d? ⁄ l Ê ú ( „ lPBStatus ˇˇòÔ ° d ONLN dG € ú Ê2 )0# function causes the driver to stor Á˙ ° d ONLN dj €2 Ê• )ñe this information in the ˇˇ1fi ‰• ° d ONLN dÑ ⁄¶ Ê– )tcsParam ˇˇòÔ ‰• ° d ONLN dã €– Ê÷ )* f N ° d ONLN dç €◊ ʯ )ield of . ° d ONLN dï Á l Ú Δ ( Ô lthe parameter block.
˜ *¯ 4 ¯ *¯
# *+¯ 4$ *+¯ $ *$˛
ˇ·ˇ‚7^
ˇˇ£‰ ˇÆ ° d ONLN d™ *"+ ( * Reference to the Device Manager ˇˇˇˇˇˇ ⁄| ( Ó1
° d ONLN d 4 l? (< l#This section describes the data str ï` ° d ONLN dÌ4 ? )îuctur @ ° d ONLN dÚ4?: )es and r ‘ ° d ONLN d˙4:?Ì )")outines that allow you to use the Device ° d ONLN d#@ lK: (H l,Manager to communicate with device drivers. ° d ONLN dPR l] ® *
The “Data Str ú ° d ONLN d]R ®] ø )<uctur " ° d ONLN dbR ¿]O ) es” section shows the Pascal defi ¿ ° d ONLN dÉRP]◊ )ê nition for the Device Manager ° d ONLN d°^ lia (f l7parameter block. The “Routines” section describes the r e¿ ° d ONLN dÿ^ai‡ )ı outines you use to open and ° d ONLN dÙj lu à (r lclose device drivers, r ]‡ ° d ONLN d j Ãu  )`ead fr ‹ ° d ONLN dj Âuú ))om and write to device drivers, and contr ¯` ° d ONLN d:júu‡ )∑ol and monitor ° d ONLN dIv lÅ! (~ l)device drivers. Constants used by these r [` ° d ONLN drv!ÅL )µ
outines ar ¿ ° d ONLN d|vMÅÍ ),$e listed in the section “Summary of ° d ONLN d†Ç lç ƒ (ä lthe Device Manager Å` ° d ONLN d≤Ç ƒç € )X,” on H@ ° d ONLN d∏Ç ‹ç ¸ )page 1- w ° d ONLN døÇ ¸ç ) 37 w ° d ONLN d¡Çç )
. ° d ONLN d√î lü ± (ú lThe chapter “W ¿¿ ° d ONLN d—î ±ü À )Eriting y` ° d ONLN dÿî Ãü “ )Y 9‡ ° d ONLN dŸî “ü‘ )9our Own Device Driver” in this book describes the Device ° d ONLN d† l´ ∑ (® lManager data str Œ ° d ONLN d"† ∑´ Œ )Kuctur T ° d ONLN d'† œ´ Ò )es and r ¿ ° d ONLN d/† Ú´≥ )#+outines useful when writing a device driver ߆ ° d ONLN dZ†≤´¥ )¿.
ÿ *‡¯ 4Ÿ *‡¯ Ÿ *Ÿ˛
ˇ·ˇ‚7^
ˇˇ◊ ˇ◊ ° d ONLN d\» *ÿ b (‘ *Data Str µ ° d ONLN dd» bÿ Ü )8uctur ôú ° d ONLN di» áÿ î )%es ˇˇˇˇˇˇ • (‘1
° d ONLN dl l ‘ (Ì lThe Device Manager pr d@ ° d ONLN dÅ ‘ø )h7ovides both a high-level and a low-level interface for ° d ONLN d∏Ò l¸ (˘ l#communicating with device drivers. ≥¿ ° d ONLN d€Ò¸ )¢Y t@ ° d ONLN d‹Ò¸∫ )&ou pass information to the low-level r ï† ° d ONLN dÒ∫¸Ô )¶
outines in a ° d ONLN d˝ l ( l Device Manager parameter block. ° d ONLN d0 l” *OThe Device Manager uses two forms of the parameter block: one for the opening, ° d ONLN d l& î *
closing, r ô ° d ONLN dâ î& Ò )(eading, and writing r 6† ° d ONLN dû Ú&s )^ outines and another for contr 4Ä ° d ONLN dªs&÷ )Åolling and monitoring ° d ONLN d—' l2 o (/ lr E ° d ONLN d“' p2 ˝ ) outines. Other managers use dif V ° d ONLN dÒ' ˝2 )çfer 8† ° d ONLN dÙ' 2 ) ent variants of this data str &† ° d ONLN d'2ñ )vuctur ¨Ä ° d ONLN d'ñ2ù )e. ˇÜ @ ˇ ˇˇˇˇ @
ˇ·ˇ‚7^
4 H \ , Palatino
. +ä"CHAPTER œ´ )\1 , Helvetica
( @ äThe Device Manager 4⁄ ä˙ (‡ ä Reference to the Device Manager
. ° d ONLN d \ H h f ( e HTYPE ° d ONLN d j T v¬ + =ParamBlkType = {ioParam, fileParam, volumeParam, cntrlParam}; ° d ONLN d F x T Ñ ¥ *ParamBlockRec = ° d ONLN d Y Ü f í ä +RECORD ° d ONLN d c î x † ú +qLink: ° d ONLN d n î “ † )Z QElemPtr; ° d ONLN d { î †Ü )H{next queue entry} ° d ONLN d ë ¢ x Æ ú ( ´ xqType: ° d ONLN d ú ¢ “ Æ )ZInteger; ° d ONLN d ® ¢ Æb )H {queue type} ° d ONLN d ∏ ∞ x º ¢ ( π xioTrap: ° d ONLN d ƒ ∞ “ º )ZInteger; ° d ONLN d – ∞ ºh )H
{routine trap ° d ONLN d · ∞h ºn )N} ° d ONLN d Ê æ x ¥ ( « x
ioCmdAddr: ° d ONLN d ı æ “ Í )ZPtr; ° d ONLN d ˝ æ z )H{routine address ° d ONLN d æz Ä )`} ° d ONLN d à x ÿ Δ ( ’ x
ioCompletion: ° d ONLN d) Ã “ ÿ )ZProcPtr; ° d ONLN d5 Ã ÿí )H{completion routine} ° d ONLN dM ⁄ x Ê Æ ( „ x ioResult: ° d ONLN d[ ⁄ “ Ê ˆ )ZOSErr; ° d ONLN de ⁄ Êh )H
{result code} ° d ONLN dv Ë x Ù ¥ ( Ò x
ioNamePtr: ° d ONLN dÖ Ë “ Ù )Z
StringPtr; ° d ONLN dì Ë Ùb )H {driver name ° d ONLN d£ Ëb Ùh )H} ° d ONLN d® ˆ x Æ ( ˇ x ioVRefNum ° d ONLN d≤ ˆ Æ ¥ )6: ° d ONLN d∑ ˆ “ )$Integer; ° d ONLN d√ ˆÊ )H"{volume reference or drive number} ° d ONLN dÈ x (
xCASE ParamBlkType OF ° d ONLN d ä ∫ +ioParam: ° d ONLN d ä, “ * (ioRefNum: ° d ONLN d “, )H Integer; ° d ONLN d- ,,º )Z{driver reference number ° d ONLN dM º,¬ )ê} ° d ONLN dT. ú: ÿ (7 ú
ioVersNum: ° d ONLN db. ‰:, )H SignedByte; ° d ONLN ds.>:t )Z {not used ° d ONLN d.t:z )6} ° d ONLN dÜ< úH ÿ (E ú
ioPermssn: ° d ONLN dî< ‰H, )H SignedByte; ° d ONLN d•<>H¬ )Z{read/write permission ° d ONLN d¬<¬H» )Ñ} ° d ONLN d…J úV Δ (S úioMisc: ° d ONLN d‘J ‰V )H Ptr; ° d ONLN dfiJ>Vz )Z
{not used} ° d ONLN dÓX úd “ (a ú ioBuffer: ° d ONLN d˚X ‰d )H Ptr; ° d ONLN dX>dŒ )Z{pointer to data buffer} ° d ONLN d#f úr fi (o ú ioReqCount: ° d ONLN d2f ‰r )H LongInt; ° d ONLN d@f>r⁄ )Z{requested number of bytes ° d ONLN dbf⁄r‡ )ú} ° d ONLN dit úÄ fi (} ú ioActCount: ° d ONLN dxt ‰Ä )H LongInt; ° d ONLN dÜt>Ä» )Z{actual number of bytes ° d ONLN d§t»ÄŒ )ä} ° d ONLN d´Ç úé ÿ (ã ú
ioPosMode: ° d ONLN dπÇ ‰é )H Integer; ° d ONLN d«Ç>é§ )Z{positioning mode ° d ONLN d›Ç§é™ )f} ° d ONLN d‰ê úú ‰ (ô ú ioPosOffset: ° d ONLN dÙê ‰ú Í )H ° d ONLN dıê Íú ) LongInt); ° d ONLN dê>ú∞ )T{positioning offset ° d ONLN d ê∞ú∂ )r} ° d ONLN d"û ä™ Ã (ß ä cntrlParam: ° d ONLN d2¨ ä∏ ÿ *
(ioCRefNum: ° d ONLN dD¨ ‰∏ )Z Integer; ° d ONLN dR¨>∏Œ )Z{driver reference number ° d ONLN dr¨Œ∏‘ )ê} ° d ONLN dy∫ úΔ Δ (√ úcsCode: ° d ONLN dÑ∫ ‰Δ, )H SignedByte; ° d ONLN dï∫>Δû )Z{type of request ° d ONLN d™∫ûΔ§ )`} ° d ONLN d±» ú‘ à (— úcsParam: ° d ONLN dΩ» ‰‘Ä )H ARRAY[1..10] OF Integer); ° d ONLN dÓ÷>‚» +Z{control or status info ° d ONLN d÷»‚Œ )ä} ° d ONLN d ‰ x ê (Ì xEND; ° d ONLN dÚ f˛ ~ (˚ fEND;
H 4 H
. ° d ONLN dˇˇ +$Field descriptions
ˇ·ˇ‚7^
. ° d ONLN d ä& ® *qLink . ° d ONLN d Ê&ì )\%Used internally by the Device Manager Î` ° d ONLN dCí&ó )¨. . ° d ONLN dF) ä5 ® (2 äqType . ° d ONLN dL* Ê5ì )\%Used internally by the Device Manager Î` ° d ONLN dq*í5î )¨. . ° d ONLN ds8 äD Æ (A äioTrap . ° d ONLN dz9 ÊDì )\%Used internally by the Device Manager Î` ° d ONLN dü9íDî )¨. . ° d ONLN d°G äS ¿ (P ä ioCmdAddr . ° d ONLN d´H ÊSì )\%Used internally by the Device Manager Î` ° d ONLN d–HíSî )¨. . ° d ONLN d“V äb “ (_ ä ioCompletion . ° d ONLN dflW Êb )\Specifi ‡ ° d ONLN dÊWbÉ ) es a pointer to a completion r ɇ ° d ONLN dWÑbÊ )Åoutine. When making ° d ONLN dc Ên (k Êasynchr $ ° d ONLN d c n* )#onous r i† ° d ONLN d&c*n£ )! equests, you must set this fi N† ° d ONLN dCc§n— )z
eld to NIL ? ° d ONLN dMc—n¯ )-
if you ar à ° d ONLN dWc¯n )'e not ° d ONLN d]o ÊzU (w Êspecifying a completion r 1¿ ° d ONLN dvoVz )p)outine. The Device Manager automatically . ° d ONLN dü{ ÊÜ (É Ê sets this fi ° d ONLN d´{Ü5 )1eld to ° d ONLN d≤z5ÜG ) NIL !† ° d ONLN dµ{Gܺ ) when you make a synchr Ù ° d ONLN dÃ{ªÜ⁄ )tonous r Δ` ° d ONLN d”{⁄ܢ ) equest. ° d ONLN d€â äï ∫ (í äioResult . ° d ONLN d‰ä Êïù )\)Contains a value indicating whether the r î ° d ONLN d
° d ONLN d ] » hÖ ( e »*detect when the driver has completed the r ‰` ° d ONLN d * ]Ö hÚ )Ωequest and to determine ° d ONLN d B i » t ÿ ( q »its r ,¿ ° d ONLN d G i Ÿ tŸ )8esult code. The Device Manager executes the completion r K† ° d ONLN d iŸ t˜ ( qŸoutine ° d ONLN d Ü u » Ä ˜ ( } » after this fi ` ° d ONLN d ì u ¯ Ä )0eld r + ° d ONLN d ò u ÄB )
eceives the r f@ ° d ONLN d • uB Äq )6 esult code. ,
Courier . ° d ONLN d ± É l è ¢ ( å l ioNamePtr . ° d ONLN d ª Ñ » èS )\ Points to the name of the driver ° d ONLN d € ÑS èX )ã. QÄ ° d ONLN d › ÑX è^ )Y ° d ONLN d fi Ñ^ èñ )
ou use this fi b@ ° d ONLN d Ï Ññ è◊ )8eld only when ° d ONLN d ˙ ê » õ ( ò »opening a driver w` ° d ONLN d
ê õ )I. . ° d ONLN d û l ™ ¢ ( ß l ioVRefNum . ° d ONLN d ü » ™? )\Contains the drive number ° d ONLN d/ ü? ™] )w, if any ° d ONLN d7 ü\ ™¡ ) . The meaning of this fi ë‡ ° d ONLN dO ü¡ ™— )eeld ° d ONLN dS ´ » ∂I ( ≥ » depends on the device driver …@ ° d ONLN do ´H ∂≈ )Ä . The Disk Driver uses this fi ° d ONLN dç ´Δ ∂· )~eld to ° d ONLN dî ∑ » ¬% ( ø »identify disk devices.
° d ONLN d´ œ l ⁄ ( ◊ lI/O fi ‡ ° d ONLN d± œ Ä ⁄ ≈ )eld descriptions
. ° d ONLN d¬ › l È ú ( Ê lioRefNum . ° d ONLN dÀ fi » È Â )\Specifi ‡ ° d ONLN d“ fi  È" ) es the driver r s ° d ONLN d· fi# È3 )>efer @ ° d ONLN d fi4 Èm ) ence number ß ° d ONLN d fil Èn )8. . ° d ONLN dÚ Ï l ¯ ¢ ( ı l ioVersNum . ° d ONLN d¸ Ì » ¯ Û )\ Not used. . ° d ONLN d ˚ l ¢ ( l ioPermssn . ° d ONLN d ¸ » )\Contains the r π` ° d ONLN d ¸† )>"ead/write permission of the driver R† ° d ONLN d@ ¸†ı )ö. When you open a ° d ONLN dR » „ ( »driver ‡ ° d ONLN dX „‘ ), you must supply one of the following values in this fi D¿ ° d ONLN dꑉ )Òeld: . ° d ONLN dó Æ# ( ÆCONST fsCurPerm ° d ONLN dß# )` ° d ONLN d®#8 )= 0; ° d ONLN dÆ8#⁄ )${retain current permission} ° d ONLN d # Æ/ ¥ (, Æ ° d ONLN dÀ# ¥/ ∫ ) ° d ONLN dÃ# ∫/ ¿ ) ° d ONLN dÕ# ¿/ Δ ) ° d ONLN dŒ# Δ/ à ) ° d ONLN dœ# Ã/ “ ) ° d ONLN d–# “/ )
fsRdPerm ° d ONLN d⁄#/ )< ° d ONLN d€#/ )= ° d ONLN d›# /8 ) 1; ° d ONLN d·#8/§ ){allow reads only} ° d ONLN dÙ/ Æ; ¥ (8 Æ ° d ONLN dı/ ¥; ∫ ) ° d ONLN dˆ/ ∫; ¿ ) ° d ONLN d˜/ ¿; Δ ) ° d ONLN d¯/ Δ; Ã ) ° d ONLN d˘/ Ã; “ ) ° d ONLN d˙/ “; ) fsWrPerm ° d ONLN d/; )6 ° d ONLN d/; ) ° d ONLN d/;2 )= 2; ° d ONLN d
/2;8 ) ° d ONLN d /8;™ ){allow writes only} ° d ONLN d ; ÆG ¥ (D Æ ° d ONLN d ; ¥G ∫ ) ° d ONLN d!; ∫G ¿ ) ° d ONLN d"; ¿G Δ ) ° d ONLN d#; ΔG à ) ° d ONLN d$; ÃG “ ) ° d ONLN d%; “G ) fsRdWrPerm ° d ONLN d0;G8 )B= 3; ° d ONLN d6;8G» )${allow reads and writes} . ° d ONLN dPK »VG (S »The Device Manager compar ° d ONLN diKHVå )Äes subsequent r 9† ° d ONLN dxKåVœ )Dead and write r è ° d ONLN dáKœVÚ )Cequests ° d ONLN dèW »b Û (_ »
with the r uÄ ° d ONLN dôW Ûbç )+"ead/write permission of the driver ¿ ° d ONLN dªWçbØ )ö
. If the r cÄ ° d ONLN d≈WØbÌ )"equest type is ° d ONLN d‘c »ni (k »#not permitted, the Device Manager r q‡ ° d ONLN d˜cinö )° eturns a a r À ° d ONLN dcön… )1 esult code ° d ONLN do »z (w »indicating the err ò ° d ONLN d oz )Lor B¿ ° d ONLN d"o z ) . . ° d ONLN d$} lâ ê (Ü lioMisc . ° d ONLN d+~ »â Û )\ Not used. . ° d ONLN d5å lò ú (ï lioBuffer . ° d ONLN d>ç »ò& )\Points to the data buf ‡† ° d ONLN dTç&ò° )^ fer for the driver to use for r ™ ° d ONLN dsç¢ò‚ )|eads or writes. . ° d ONLN dÉõ lß ® (§ l
ioReqCount . ° d ONLN déú »ß  )\Specifi ‡ ° d ONLN dïú Âß ) es the r ô‡ ° d ONLN dùúßΔ ) ,equested number of bytes for the driver to r ª ° d ONLN d…úΔ߉ )¡ead or ° d ONLN d–® »≥ · (∞ »write. . ° d ONLN d◊∂ l¬ ® (ø l
ioActCount . ° d ONLN d‚∑ »¬ú )\1Indicates the actual number of bytes the driver r ‡ ° d ONLN d∑ù¬› )’eads or writes. . ° d ONLN d#≈ l— ¢ (Œ l ioPosMode . ° d ONLN d.Δ »—  )\Specifi ‡ ° d ONLN d5Δ Â—˜ ) ?es the positioning mode used by drivers of block devices. Bits ° d ONLN dt“ »› (⁄ »0 and 1 of this fi ¸` ° d ONLN dÜ“›Z )Feld indicate wher ª@ ° d ONLN dó“[›ÿ )M e an operation should begin ° d ONLN d≥fi »È À (Ê »r E ° d ONLN d¥fi ÃÈÌ )Aelative to the physical beginning of the block-formatted medium. ° d ONLN dıÍ »ı Œ (Ú »Y @Ä ° d ONLN dˆÍ Œı )Eou can use the following constants to test or set the value of these ° d ONLN d;ˆ » ⁄ (˛ »bits: . ° d ONLN dC »" *CONST fsAtMark ° d ONLN dR". )Z ° d ONLN dT.– ) = 0; {at current position} ° d ONLN dp » Œ ( » ° d ONLN dq Œ ‘ ) ° d ONLN dr ‘ ⁄ ) ° d ONLN ds ⁄ ‡ ) ° d ONLN dt ‡ Ê ) ° d ONLN du Ê Ï ) ° d ONLN dv Ï @ )fsFromStart = ° d ONLN dÑ@ R )T1; ° d ONLN dáR ‹ ){offset from beginning} ° d ONLN dü »( Œ (% » ° d ONLN d† Œ( ‘ ) ° d ONLN d° ‘( ⁄ ) ° d ONLN d¢ ⁄( ‡ ) ° d ONLN d£ ‡( Ê ) ° d ONLN d§ Ê( Ï ) ° d ONLN d• Ï(4 ) fsFromMark ° d ONLN d± 4(R )H= 2; ° d ONLN d∂ R(Ó ) {offset from current pos.} . ° d ONLN d“, »7 Í (4 »The Dis û` ° d ONLN dŸ, Í7Ê )":k Driver allows you to add the following constant to this ° d ONLN d8 »C Œ (@ »fi å¿ ° d ONLN d8 ŒC )eld to specify a r ¿ ° d ONLN d'8Ct )Iead-verify operation: . ° d ONLN d?F »R" (O »CONST rdVerify ° d ONLN dNF"R. )Z ° d ONLN dPF.Ræ ) = 64; {read-verify mode} ˇˇÏ‡ ° d ONLN dqV »aB (^ »See the description of the ˇˇŸ¿ ` ° d ONLN dåUCag ){PBRead ˇˇÏ‡ ` ° d ONLN díVga‘ )$ function in “Reading Fr ¶@ ° d ONLN d™V‘a˜ )mom and . ° d ONLN d±b »m “ (j »W ¬† ° d ONLN d≤b —m Ú ) riting T fi† ° d ONLN d∫b Òm3 ) o Devices,” on '` ° d ONLN d…b4mT )Cpage 1- V ° d ONLN d–bTm^ ) 25 V ° d ONLN d“b^m` )
. . ° d ONLN d‘p l| Æ (y l ioPosOffset . ° d ONLN d‡q »|  )\Specifi ‡ ° d ONLN dÁq Â| ) es the byte of ` ° d ONLN dıq |8 );fset, r u@ ° d ONLN d¸q8|∂ ) elative to the position specifi ”‡ ° d ONLN dq∂|· )~
ed by the ° d ONLN d%} »à1 (Ö »positioning mode, wher =` ° d ONLN d;}2àÔ )j+e the driver should perform the operation. ˇ˛≥3 . ° d ONLN dfâ »î (ë »If you specify the ˇ˝ff Là ° d ONLN dyàîH )PfsAtMark ˇ˛≥3 Là ° d ONLN dÅâHî¯ )0& positioning mode, the Device Manager . ° d ONLN dßï »† fl (ù »ignor ` ° d ONLN d¨ï ‡† ) es this fi O‡ ° d ONLN d∂ï† )$eld. ˇÜ @ ˇ ˇˇˇˇ @
ˇ·ˇ‚7^
4 H \ , Palatino
. +ä"CHAPTER œ´ )\1 , Helvetica
( @ äThe Device Manager 4⁄ ä˙ (‡ ä Reference to the Device Manager
° d ONLN d \ ä g · ( d äControl and status fi ˙– ° d ONLN d \ · g& )Weld descriptions ,
Courier
. ° d ONLN d & j ä v ¿ ( s ä ioCRefNum . ° d ONLN d 0 k Ê vB )\Contains the driver r í† ° d ONLN d E kB vR )\efer >¿ ° d ONLN d I kS vå ) ence number Δ† ° d ONLN d T kã vç )8. . ° d ONLN d V y ä Ö Æ ( Ç äcsCode . ° d ONLN d ] z Ê Öæ )\2Contains a value identifying the type of the contr L ° d ONLN d è zø ÖÚ )Ÿ
eld is declar < ° d ONLN d7 °4 ¨ )53ed generically as an array of ten integers because ° d ONLN dj ≠ Ê ∏T ( µ Êits actual format varies fr ˝ ° d ONLN dÖ ≠T ∏Ø )nom one type of contr | ° d ONLN dô ≠∞ ∏Á )\ol or status r ç ° d ONLN dß ≠Á ∏ )7
equest to ° d ONLN d± π Ê ƒ ( ¡ Ê the next.
Ò H ˘ 4 Ú H ˘ Ú H Ú
ˇ·ˇ‚7^
ˇˇ◊ ˇ◊ ° d ONLN dª · H Ò Ö ( Ì HRoutines ˇˇˇˇˇˇ • ( Ì1
° d ONLN dƒ ˛ ä K ( ä+This section describes the Device Manager r ˇ† ° d ONLN dÔ ˛K )¡)outines you use to open and close device ° d ONLN d
ä ≤ ( ä
drivers, r €@ ° d ONLN d"
≤ À )(ead fr YÄ ° d ONLN d(
ÃÉ ))om and write to device drivers, and contr u¿ ° d ONLN dQ
É )∑ ol and monitor device drivers. ° d ONLN dq ä' Ã ($ äThe low-level r ¿ ° d ONLN dÄ Õ'Ë )CCoutines in this section accept a pointer to a parameter block as a ° d ONLN d√( ä3 ∑ (0 ä parameter S† ° d ONLN dÃ( ∑3 Í )-
. For these r Û‡ ° d ONLN dŸ( Í3# )3outines, the r ï† ° d ONLN dÁ($3◊ ):+outine description includes a list of the fi x‡ ° d ONLN d(ÿ3 )¥ elds in the ° d ONLN d 4 ä? Ò (< äparameter block that ar ë ° d ONLN d64 Ò?1 )ge used by the r =@ ° d ONLN dE42?P )Aoutine.
c Hk 4d Hk d Hd
ˇ·ˇ‚7^
° d ONLN dMV Hc (` H"Opening and Closing Device Drivers ˇˇˇˇˇˇ (`1
° d ONLN dpl äw ë (t äA ∫† ° d ONLN dql ëw ) driver must be open befor 1‡ ° d ONLN dãlwà )v,e your application can communicate with it.
Ä ° d ONLN d∑lÃw“ )≈Y Œ ° d ONLN d∏l—w )ou can use the . ° d ONLN d«w äÉ Δ (Ä ä
OpenDriver ° d ONLN d—x ΔÉ ’ )< or ° d ONLN d’w ’É ˘ )PBOpen ° d ONLN d€x ˘É )$< function to open closed drivers or to determine the driver ˇˇœÎ ° d ONLN dÑ äè é (å är R` ° d ONLN dÑ éè † )efer $¿ ° d ONLN d Ñ †è )ence number of an alr 6à ° d ONLN d1Ñ èo )`eady open device driver È- ° d ONLN dHÑnès )n. ãx ° d ONLN dJÑtè{ )Y †x ° d ONLN dKÑzèº )ou can use the ˇˇü÷ ‡$ ° d ONLN dZɺèÏ )BOpenSlot ˇˇœÎ ‡$ ° d ONLN dbÑÏè )0
function . ° d ONLN dlê äõ3 (ò ä(to open drivers that serve slot devices. ° d ONLN dï¢ ä≠ ÿ *When you have fi Δ ° d ONLN d•¢ ÿ≠y )N"nished communicating with a driver ¨¿ ° d ONLN d«¢y≠È )° , you can close it if you ar † ° d ONLN d„¢Í≠ˇ )qe sur Y` ° d ONLN dË¢ˇ≠ )e no ˇˇ.ü . ° d ONLN dÌÆ äπÅ (∂ ä9other application or part of the system needs to use it. S5 ° d ONLN d&ÆÅπà )˜Y h5 ° d ONLN d'ÆáπΔ )ou can use the ˇ˛]> "± ° d ONLN d6≠«π )@ CloseDriver ˇˇ.ü "± ° d ONLN dAÆ π )B or ° d ONLN dEπ ä≈ ¥ (¬ äPBClose ° d ONLN dL∫ ¥≈) )* function to close a driver ¬† ° d ONLN dg∫(≈+ )t. ° d ONLN dià ä◊ ü (‘ äThe ° d ONLN dmÀ ü◊ √ )PBOpen ° d ONLN dsà √◊ ⁄ )$ and ° d ONLN dxÀ ⁄◊ )PBClose ° d ONLN dÃ◊q )* functions use the I/O fi ° d ONLN dòÃq◊ )m!elds of the parameter block. The ˇ˝ ∏ ° d ONLN dπ◊ ä„ ∫ (‡ äOpenSlot ˇ˛é‹ ° d ONLN d¡ÿ ∫„ )0 function uses the I/O f à ° d ONLN dŸÿ „ó )cields and some additional f &º ° d ONLN dÙÿó„ )z ields that apply only to slot . ° d ONLN d‰ äÔ ≠ (Ï ädevices.
H' 4 H' H
ˇ·ˇ‚7^
° d ONLN d H ä ( H
OpenDriver ˇˇˇˇˇˇ ( 1
ˇˇ>∞ . ° d ONLN d'2 ä= ë (: äY ï ° d ONLN d(2 ê= œ )ou can use the ˇ˛}` è¿ ° d ONLN d71 –= )@
| Èá ) #es the name of the driver to open. 0 ° d ONLN d-|Äáá )óA j† ° d ONLN d.|áá˙ ) driver name consists of a ° d ONLN dIà Ãì (ê ÃIperiod (.) followed by any sequence of 1 to 254 printing characters. The ° d ONLN díî Ãü. * Device Manager ignor ‰¿ ° d ONLN d¶î.ü )b3es case (but not diacritical marks) when comparing ° d ONLN dŸ† ô Î (® Ãnames. ˇ ‡ @ ˇ ˇˇˇˇ @
. ° d ONLN d \ l h ê ( e lrefNum ° d ONLN d ] Æ h )BContains the r R` ° d ONLN d ] h )Befer $¿ ° d ONLN d ] hw )ence number of the driver g` ° d ONLN d 2 ]v hë )t. The g` ° d ONLN d 8 \ë hÕ )
OpenDriver g` ° d ONLN d B ]Õ h˜ )<
function . ° d ONLN d L i Æ t ( q Æuses this parameter to r ¿ ° d ONLN d d i tD )h eturn the r ã@ ° d ONLN d o iD tT ).efer 7` ° d ONLN d s iU t‡ ) ence number of the open driver —‡ ° d ONLN d ë ifl t· )ä.
parameter }J ° d ONLN d' ™Z µ“ )1. The Device Manager sear vB ° d ONLN d@ ™“ µ˙ )x ches the . ° d ONLN dI ∂ l ¡ ™ ( æ ldrivers that ar 1` ° d ONLN dX ∂ ´ ¡ æ )?e alr (` ° d ONLN d] ∂ æ ¡] )&eady installed in the unit table befor Ç ° d ONLN dÉ ∂] ¡v )üe sear ó` ° d ONLN dâ ∂v ¡≤ )ching driver r @ ° d ONLN dó ∂≥ ¡À )=esour à` ° d ONLN dú ∂À ¡Ê )ces to ° d ONLN d£ ¬ l Õ ã ( lavoid r ‰‡ ° d ONLN d™ ¬ ã Õ Ã ) eplacing a curr Å ° d ONLN dπ ¬ Õ Õ ¯ )B
ent driver z` ° d ONLN d√ ¬ ¯ Õ2 )+. If the specifi x@ ° d ONLN d” ¬3 Õs );ed driver is alr † ° d ONLN d„ ¬t Õ· )Aeady open, this function ° d ONLN d¸ Œ l Ÿ ê ( ÷ lsimply r 8 ° d ONLN d Œ ë Ÿ € )%eturns the driver @ ° d ONLN d Œ ‹ Ÿ È )K’s r â` ° d ONLN d Œ È Ÿ ˘ )
efer 5Ä ° d ONLN d Œ ˙ Ÿ3 ) ence number Ω` ° d ONLN d( Œ2 Ÿ7 )8. ° d ONLN d+ ‡ l Î ° ( Ë l
If the specifi }‡ ° d ONLN d9 ‡ ¢ Î Û )6ed driver is not alr Ä ° d ONLN dM ‡ Ù Îî )R"eady open, the Device Manager sear * ° d ONLN do ‡î Îfi )†ches for a driver ° d ONLN dÅ Ï l ˜ o ( Ù lr E ° d ONLN dÇ Ï p ˜ à )esour ç@ ° d ONLN dá Ï à ˜ ◊ )ce with the specifi ¿ ° d ONLN dö Ï ◊ ˜l )O ed name. If the Device Manager fi 8 ° d ONLN dª Ïm ˜¢ )ñ nds such a r ,‡ ° d ONLN d« Ï¢ ˜∫ )5esour u ° d ONLN dà Ï∫ ˜ÿ )ce, the ° d ONLN d‘ ¯ l o ( lr E ° d ONLN d’ ¯ p à )esour ç@ ° d ONLN d⁄ ¯ àj )4ce ID determines the location in the unit table wher ≈¿ ° d ONLN d ¯jÓ )‚ e the Device Manager installs ° d ONLN d, l ó ( l
enumber the r Î ° d ONLN d ˛' )>esour 3` ° d ONLN d ': )ce accor @ ° d ONLN d :'p )# dingly befor D ° d ONLN d p' )6 e calling this function. See ° d ONLN d8( l3 À (0 lListing 1-1 on page 1- ï‡ ° d ONLN dN( À3 – )_8 ï‡ ° d ONLN dO( –3 ) for an example. ˇ˛ˇ˛ . ° d ONLN d`7 lB (? lThe ˇ˝ˇ¸ ˛ ° d ONLN dd6 ÄB º )
OpenDriver ˇ˛ˇ˛ ˛ ° d ONLN dn7 ºBó )<3 function is a high-level version of the low-level ˇ˝ˇ¸ Ï ° d ONLN d°6òBº )‹PBOpen ˇ˛ˇ˛ Ï ° d ONLN dß7ºB˘ )$ function. Use ˇˇ%√ ° d ONLN d∂C lN ~ (K lthe ˇ˛KÜ •√ ° d ONLN d∫B ~N ¢ )PBOpen ˇˇ%√ •√ ° d ONLN d¿C ¢NA )$$ function when you need to specify r Äx ° d ONLN d‰CAN„ )ü#ead/write permission for the driver Z$ ° d ONLN dC„N˙ )¢. See ° d ONLN d
O lZ ‘ (W lthe description of the ° d ONLN d$N ‘Z ¯ )hPBOpen ° d ONLN d*O ¯Z/ )$
function on , Times ° d ONLN d7N/ZL )7page 1- ° d ONLN d>NLZV ) 18 ° d ONLN d@OVZY )
.
. ° d ONLN dBu *} L ({ *SPECIAL U ° d ONLN dIu M} Å )#
CONSIDERA Á ° d ONLN dSu Ä} ö )3TIONS
ˇˇ⁄& . ° d ONLN dYÑ lè Ä (å lThe ˇˇ¥L Z& ° d ONLN d]É Åè Ω )
OpenDriver ˇˇ⁄& Z& ° d ONLN dgÑ ΩèŒ )<; function may move memory; you should not call it at interr •» ° d ONLN d¢ÑŒè˜ (åŒ upt time.
. ° d ONLN d¨™ *≤ D (∞ *RESUL èU ° d ONLN d±™ D≤ h )T CODES
. ° d ONLN dπ∏ lƒ ä +(noErr . ° d ONLN døπ ¯ƒ ˝ )å0 ° d ONLN d¡πƒ- )No err E† ° d ONLN d«π.ƒ7 ) or . ° d ONLN d √ lœ ® (à l
badUnitErr . ° d ONLN d’ƒ Óœ ˝ )Ç–21 ° d ONLN dŸƒœ( )#Refer ⁄ ° d ONLN dfiƒ(œ” )&ence number out of range or not in use . ° d ONLN dŒ l⁄ ¥ (◊ l unitEmptyErr . ° d ONLN dœ Ó⁄ ˝ )Ç–22 ° d ONLN dœ⁄Å )#DCE points to null driver . ° d ONLN d0Ÿ l ñ (‚ lopenErr . ° d ONLN d8⁄ Ó ˝ )Ç–23 ° d ONLN d<⁄Âs )#Driver can’t perform r Y` ° d ONLN dR⁄sÂ≥ )b
equested open . ° d ONLN d`‰ l ú (Ì ldInstErr . ° d ONLN diÂ Ó ˝ )Ç–26 ° d ONLN dmÂ@ )#
Couldn’t fi Ä ° d ONLN dxÂA| )0nd driver in r ƒ† ° d ONLN dÜÂ|î );esour ‡ ° d ONLN dãÂï¶ )ce fi ”Ä ° d ONLN dê¶≠ )le
° d ONLN dì
* Q ( *SEE ALSO
° d ONLN dú l$ +B%For information about the low-level r Ɔ ° d ONLN d¡$È )§3outines for opening devices, see the next section, ˇˇbt . ° d ONLN dÙ% l0 (- lwhich describes the ˇ˛ƒË ß\ ° d ONLN d$ 0 Ó )^PBOpen ˇˇbt ß\ ° d ONLN d% Ó0í )$& function, and the description of the ˇ˛ƒË Xà ° d ONLN d4$ì0√ )•OpenSlot ˇˇbt Xà ° d ONLN d<%√0¯ )0
function on . ° d ONLN dI1 l< å (9 lpage 1- Æ¿ ° d ONLN dP1 å< ñ ) 20 Æ¿ ° d ONLN dR1 ñ< ò )
. ° d ONLN dTC lN& (K l)For an example of opening a device driver ±† ° d ONLN d}C&N; )∫, see ‡ ° d ONLN dÉC<Nõ )Listing 1-1 on page 1- ¿ ° d ONLN dôCõN† )_8 ¿ ° d ONLN döC†N¢ ).
~ *ܯ 4 *ܯ *˛
ˇ·ˇ‚7^
° d ONLN dùq *~ W ({ *PBOpen ˇˇˇˇˇˇ ({Ú1
. ° d ONLN d§ë lú s (ô lY ï ° d ONLN d•ë rú µ )ou can use the ï ° d ONLN d¥ê µú Ÿ )CPBOpen ï ° d ONLN d∫ë ŸúÏ )$= function to open a closed device driver or to determine the . ° d ONLN d˜ù l® o (• lr E ° d ONLN d¯ù p® Ä )efer Ò ° d ONLN d¸ù Ä®' )$ence number of an open device driver ≠Ä ° d ONLN d ù'®) )ß. ˇ ® @ ˇ ˇˇˇˇ @
ˇ·ˇ‚7^
4 H \ , Palatino
. +ä"CHAPTER œ´ )\1 , Helvetica
( @ äThe Device Manager 4⁄ ä˙ (‡ ä Reference to the Device Manager
. ° d ONLN d \ ä h ‰ ( e äFUNCTION PBOpen ° d ONLN d \ ‰ h Í )Z ° d ONLN d \ Í hz )(paramBlock: ParmBlkPtr; ° d ONLN d 9 j ‰ v Í ( s ‰ ° d ONLN d : j Í v ) ° d ONLN d ; j vz )async: Boolean): OSErr; ° d ONLN d S Ç ä é Δ ( ã ä
paramBlock . ° d ONLN d ^ É Ã éÜ )B*Contains a pointer to the parameter block. . ° d ONLN d â í ä û ® ( õ äasync . ° d ONLN d è ì à û È )BSpecifi ‡ ° d ONLN d ñ ì È ûñ ) &es to the Device Manager whether the r RÄ ° d ONLN d º ìó ûΩ )Æ equest is . ° d ONLN d « ü à ™ ( ß Ãasynchr R` ° d ONLN d Œ ü ™ )$onous. $¿ ° d ONLN d ’ ü ™ ) Y 9¿ ° d ONLN d ÷ ü ™ï )ou should always set this fi 9¿ ° d ONLN d Ú üï ™≥ )Åeld to 9¿ ° d ONLN d ˘ û≥ ™— ) FALSE 9¿ ° d ONLN d ˛ ü— ™‘ ) . . ° d ONLN d ± ä º ê ( π äY @Ä ° d ONLN d ± ê º ˆ )ou specify values and r P ° d ONLN d ± ˆ º )feceive r ¿ ° d ONLN d ± º¯ )!1eturn values in a Device Manager parameter block.
… H Ÿ 4 H ÿ
° d ONLN dˇˇ ( — äParameter block
ˇ·ˇ‚7^ , Symbol
° d ONLN dˇˇ *Æ . ° d ONLN dˇˇ ) ioCompletion ° d ONLN dˇˇ )QProcPtr . ° d ONLN dˇˇ )8A ∫† ° d ONLN dˇˇ ) pointer to completion r G ° d ONLN dˇˇ )ioutine. ° d ONLN dˇˇ ( Î ä¨ . ° d ONLN dˇˇ ) ioResult ° d ONLN dˇˇ )QOSErr . ° d ONLN dˇˇ )8The r Ä¿ ° d ONLN dˇˇ )esult code of the function. ° d ONLN dˇˇ ( ˜ äÆ . ° d ONLN dˇˇ ) ioNamePtr ° d ONLN dˇˇ )Q StringPtr . ° d ONLN dˇˇ +8 A ∫† ° d ONLN dˇˇ ) pointer to the driver name. ° d ONLN dˇˇ ( ä¨ . ° d ONLN dˇˇ ) ioRefNum ° d ONLN dˇˇ )QInteger . ° d ONLN dˇˇ )8 The driver r Z ° d ONLN dˇˇ )5efer ° d ONLN dˇˇ ) ence number é ° d ONLN dˇˇ )8. ° d ONLN dˇˇ ( äÆ . ° d ONLN dˇˇ ) ioPermssn ° d ONLN dˇˇ )Q SignedByt ° d ONLN dˇˇ )6e . ° d ONLN dˇˇ + Read/write permission.
° d ONLN dêR HZ Å (X H DESCRIPTION
. ° d ONLN dú` äk ü +BThe ° d ONLN d†_ ük √ )PBOpen ° d ONLN d¶` √k{ )$( function opens the device driver specifi ° d ONLN dœ`{k™ )∏
ed by the ° d ONLN dŸ_™k‡ )/ ioNamePtr ° d ONLN d‚`‡kÍ )6 fi ° d ONLN dÂ`Íkˇ )
eld, ˇˇ˘y ° d ONLN dÍl äw ˙ (t äinstalling it if necessary P´ ° d ONLN dl ˙w )p, and r ˝ ° d ONLN d lwH ) eturns its r €O ° d ONLN dlHwZ )0efer ≠Ø ° d ONLN dlZw± )ence number in the ˇˇÚÚ ìì ° d ONLN d.k≤w‚ )XioRefNum ˇˇ˘y ìì ° d ONLN d6l‚wÎ )0 fi ç ° d ONLN d9lÏw )
eld. The . ° d ONLN dBx äÉ Ê (Ä äDevice Manager sear - ° d ONLN dUx ÁÉL )]ches the drivers that ar ° d ONLN dmxLÉ_ )ee alr ˚ ° d ONLN drx^É˝ )&eady installed in the unit table befor T¿ ° d ONLN dòx˛É )†e ° d ONLN döÑ äè õ (å äsear K† ° d ONLN dûÑ úè ÿ )ching driver r Ù` ° d ONLN d¨Ñ ÿè )<esour <† ° d ONLN d±Ñ Òè+ )ces to avoid r –@ ° d ONLN døÑ+èl ):eplacing a curr lÄ ° d ONLN dŒÑmèò )B
ent driver e¿ ° d ONLN dÿÑòè“ )+. If the specifi c† ° d ONLN dËÑ”è );
ed driver is ° d ONLN dıê äõ ï (ò äalr -` ° d ONLN d¯ê ñõ ) eady open, this function r @‡ ° d ONLN dêõW )qeturns the driver r –† ° d ONLN d%êWõg )Pefer |¿ ° d ONLN d)êhõØ )ence number alr Ô` ° d ONLN d8êØõ )Geady belonging to the ° d ONLN dNú äß • (§ ädriver ‡ ° d ONLN dTú •ß ß ). ° d ONLN dVÆ äπ ø (∂ ä
If the specifi }‡ ° d ONLN ddÆ ¿π )6ed driver is not alr Ä ° d ONLN dxÆπ≤ )R"eady open, the Device Manager sear * ° d ONLN döÆ≤π¸ )†ches for a driver ° d ONLN d¨∫ ä≈ ç (¬ är E ° d ONLN d≠∫ é≈ ¶ )esour ç@ ° d ONLN d≤∫ ¶≈ ı )ce with the specifi ¿ ° d ONLN d≈∫ ı≈ä )O ed name. If the Device Manager fi 8 ° d ONLN dÊ∫ã≈¿ )ñ nds such a r ,‡ ° d ONLN dÚ∫¿≈ÿ )5esour u ° d ONLN d˜∫ÿ≈ˆ )ce, the ° d ONLN dˇΔ ä— ç (Œ är E ° d ONLN d Δ é— ¶ )esour ç@ ° d ONLN dΔ ¶—à )4ce ID determines the location in the unit table wher ≈¿ ° d ONLN d9Δà— )‚ e the Device Manager installs ° d ONLN dW“ ä› µ (⁄ ä
enumber the r Î ° d ONLN d-Í ı4 )>esour 3` ° d ONLN d2Í5ıX )ce accor @ ° d ONLN d:ÍXıé )# dingly befor D ° d ONLN dFÍéı )6 e calling this function. See ° d ONLN dcˆ ä È (˛ äListing 1-1 on page 1- ï‡ ° d ONLN dyˆ È Ó )_8 ï‡ ° d ONLN dzˆ Ó5 ) for an example. ° d ONLN dã ä ≈ (
äIf the driver r Æ ° d ONLN dö ≈ );eturns a negative r À‡ ° d ONLN d≠= )R
esult in r É ° d ONLN d∑>Œ )' egister D0, the Device Manager r @‡ ° d ONLN d◊œ˝ )ë eturns the . ° d ONLN d‚ ä é ( är R` ° d ONLN d„ é › )esult code in the R` ° d ONLN dı ›
)OioResult R` ° d ONLN d˝
« )0' parameter and does not open the driver ï ° d ONLN d$Δ … )π.
. ° d ONLN d&8 H@ j (> HSPECIAL U ° d ONLN d-8 k@ ü )#
CONSIDERA Á ° d ONLN d78 û@ ∏ )3TIONS
. ° d ONLN d=F äQ ü (N äThe ° d ONLN dAE üQ √ )PBOpen ° d ONLN dGF √Q÷ )$; function may move memory; you should not call it at interr l ° d ONLN dÇF÷Q (N÷ upt time.
. ° d ONLN dåm Hu n (s HASSEMBL ‹è ° d ONLN dìm nu r )&Y ö∫ ° d ONLN dîm su – )-LANGUAGE INFORMA —U ° d ONLN d•m –u  )]TION
ˇˇÎ· . ° d ONLN d™{ äÜ À (É ä
The trap macr *" ° d ONLN d∑{ ÃÜ ˆ )B
o for the ˇˇ◊¬ Ì≈ ° d ONLN d¡z ˆÜ )*PBOpen ˇˇÎ· Ì≈ ° d ONLN d«{ÜN )$
function is ˇˇ◊¬ ±h ° d ONLN d‘zOÜm )5_Open ˇˇÎ· ±h ° d ONLN dŸ{mÜö )
($A000). [ä ° d ONLN d„{õÜ¢ ).Y pä ° d ONLN d‰{°Ü‰ )ou must setup r ç ° d ONLN dÛ{ÂÜ )Degister î ° d ONLN d˚{Ü )!A0 ˇˇ ° d ONLN d˛á äí À (è ä
with the addr ä~ ° d ONLN d á Àíd )A!ess of the parameter block. When ˇ˛8 2ÿ ° d ONLN d,ÜeíÉ )ö_Open ˇˇ 2ÿ ° d ONLN d1áÉíâ ) r !G ° d ONLN d3áâí≠ ) eturns, r ∂ ° d ONLN d<á≠í )$egister D0 contains the . ° d ONLN dTì äû ç (õ är E ° d ONLN dUì éû) )%esult code. Register D0 is the only r ∂¿ ° d ONLN dzì)ûQ )õ
egister af Ÿ¿ ° d ONLN dÑìQûí )(fected by this r $ ° d ONLN dîììû± )Boutine.
° d ONLN dú¢ ä≠ ÿ (™ äRegisters on entry
° d ONLN dر äº ñ *A0 ° d ONLN d≤± Δº € )<addr |Ä ° d ONLN d∂± €ºN )ess of the parameter block ˇÙ @ ˇ ˇˇˇˇ @
° d ONLN d k l v x *D0 ° d ONLN d k ® v ´ )<r E ° d ONLN d k ¨ v ÿ )
esult code
° d ONLN d ! ë * ô D ( ó *RESUL èU ° d ONLN d & ë D ô h )T CODES ,
Courier
. ° d ONLN d . ü l ´ ä +(noErr . ° d ONLN d 4 † ¯ ´ ˝ )å0 ° d ONLN d 6 † ´- )No err E† ° d ONLN d < †. ´7 ) or . ° d ONLN d ? ™ l ∂ ® ( ≥ l
badUnitErr . ° d ONLN d J ´ Ó ∂ ˝ )Ç–21 ° d ONLN d N ´ ∂( )#Refer ⁄ ° d ONLN d S ´( ∂” )&ence number out of range or not in use . ° d ONLN d z µ l ¡ ¥ ( æ l unitEmptyErr . ° d ONLN d á ∂ Ó ¡ ˝ )Ç–22 ° d ONLN d ã ∂ ¡Å )#DCE points to null driver . ° d ONLN d • ¿ l à ñ ( … lopenErr . ° d ONLN d ≠ ¡ Ó Ã ˝ )Ç–23 ° d ONLN d ± ¡ Ãs )#Driver can’t perform r Y` ° d ONLN d « ¡s Ã≥ )b
equested open . ° d ONLN d ’ À l ◊ ú ( ‘ ldInstErr . ° d ONLN d fi Ã Ó ◊ ˝ )Ç–26 ° d ONLN d ‚ à ◊@ )#
Couldn’t fi Ä ° d ONLN d Ì ÃA ◊| )0nd driver in r ƒ† ° d ONLN d ˚ Ã| ◊î );esour ‡ ° d ONLN d Ãï ◊¶ )ce fi ”Ä ° d ONLN d ö ◊≠ )le
° d ONLN d Ò * ˘ Q ( ˜ *SEE ALSO
° d ONLN d l +B&For information about the high-level r ° d ONLN d7 ◊ )®-outine for opening device drivers, see the pr &¿ ° d ONLN dd ◊ ˆ )√evious . ° d ONLN dk l ˝ ( l section, which describes of the ° d ONLN dã ˝9 )ë
OpenDriver ° d ONLN dï 9@ )< r R` ° d ONLN dó @_ )outine. . ° d ONLN dü l) (& l%For information about the low-level r Ɔ ° d ONLN dƒ )˜ )§5outine for opening device drivers that serve devices . ° d ONLN d˘* l5 ∑ (2 lon expansion car R` ° d ONLN d * ∑5í )K1ds, see the next section, which describes of the R` ° d ONLN d:)í5¬ )€OpenSlot R` ° d ONLN dB*¬5… )0 r $¿ ° d ONLN dD*…5Ë )outine. . ° d ONLN dL< lG& (D l)For an example of opening a device driver ±† ° d ONLN du<&G; )∫, see ‡ ° d ONLN d{<<Gõ )Listing 1-1 on page 1- ¿ ° d ONLN dë<õG† )_8 ¿ ° d ONLN dí<†G¢ ).
w *¯ 4x *¯ x *x˛
ˇ·ˇ‚7^
° d ONLN dïj *w ^ (t *OpenSlot ˇˇˇˇˇˇ (tÚ1
. ° d ONLN dûä lï s (í lY ï ° d ONLN düä rï µ )ou can use the ï ° d ONLN dÆâ µï  )COpenSlot ï ° d ONLN d∂ä ÂïÚ )0< function to open a device driver that serves a slot device. ° d ONLN dÛ° l≠ “ (™ lFUNCTION OpenSlot ° d ONLN d ° “≠b )f(paramBlock: ParmBlkPtr; ° d ONLN d-Ø Δª à (∏ Δ ° d ONLN d.Ø Ãª “ ) ° d ONLN d/Ø “ª ÿ ) ° d ONLN d0Ø ÿªh )async: Boolean) : OSErr; ° d ONLN dI« l” ® (– l
paramBlock . ° d ONLN dT» Æ”h )B*Contains a pointer to the parameter block. . ° d ONLN d◊ l„ ä (‡ lasync . ° d ONLN dÖÿ Æ„ À )BSpecifi ‡ ° d ONLN dåÿ À„x ) &es to the Device Manager whether the r RÄ ° d ONLN d≤ÿy„ü )Æ equest is . ° d ONLN dΩ‰ ÆÔ “ (Ï Æasynchr R` ° d ONLN dƒ‰ “Ô )$onous. $¿ ° d ONLN dÀ‰ Ô ˜ ) Y 9¿ ° d ONLN dÉ ˆÔw )ou should always set this fi 9¿ ° d ONLN dˉwÔï )Åeld to 9¿ ° d ONLN dÔ„ïÔ≥ ) FALSE 9¿ ° d ONLN dÙ‰≥Ô∂ ) . . ° d ONLN dˆˆ l r (˛ lY @Ä ° d ONLN d˜ˆ r ÿ )ou specify values and r P ° d ONLN dˆ ÿ ˘ )feceive r ¿ ° d ONLN dˆ ˘Ò )!6eturn values in a Device Manager parameter block with ° d ONLN dL l
º (
la few additional fi ˚ ° d ONLN d_ º
W )P%elds that apply only to slot devices.
**¯ 4 *)¯
° d ONLN dˇˇ (" lParameter block
ˇ·ˇ‚7^ , Symbol
° d ONLN dˇˇ *Æ . ° d ONLN dˇˇ ) ioCompletion ° d ONLN dˇˇ )QProcPtr . ° d ONLN dˇˇ )8Pointer to completion r ì‡ ° d ONLN dˇˇ )foutine. ° d ONLN dˇˇ (< l¨ . ° d ONLN dˇˇ ) ioResult ° d ONLN dˇˇ )QOSErr . ° d ONLN dˇˇ )8 Result code. ° d ONLN dˇˇ (H lÆ . ° d ONLN dˇˇ ) ioNamePtr ° d ONLN dˇˇ )Q StringPtr . ° d ONLN dˇˇ +8 Driver name. ° d ONLN dˇˇ (` l¨ . ° d ONLN dˇˇ ) ioRefNum ° d ONLN dˇˇ )QInteger . ° d ONLN dˇˇ )8Driver r ø¿ ° d ONLN dˇˇ )#efer k‡ ° d ONLN dˇˇ ) ence number Û¿ ° d ONLN dˇˇ )8. ° d ONLN dˇˇ (l lÆ . ° d ONLN dˇˇ ) ioPermssn ° d ONLN dˇˇ )Q SignedByt ° d ONLN dˇˇ )6e . ° d ONLN dˇˇ + Read/write permission. ˇ\ @ ˇ ˇˇˇˇ @
ˇ·ˇ‚7^
4 H \ , Palatino
. +ä"CHAPTER œ´ )\1 , Helvetica
( @ äThe Device Manager 4⁄ ä˙ (‡ ä Reference to the Device Manager
° d ONLN dˇˇ ( d ä Additional fi |0 ° d ONLN dˇˇ )4elds—single device , Symbol
° d ONLN dˇˇ ( s äÆ ,
Courier . ° d ONLN dˇˇ ) ioMix ° d ONLN dˇˇ )QPtr . ° d ONLN dˇˇ )8!Reserved for use by driver Open r Ù@ ° d ONLN dˇˇ )ñoutine. ° d ONLN dˇˇ ( äÆ . ° d ONLN dˇˇ ) ioFlags ° d ONLN dˇˇ )QInteger . ° d ONLN dˇˇ )8!Determines number of additional fi ⁄@ ° d ONLN dˇˇ )úelds. . ° d ONLN dˇˇ ( ã äÆ ° d ONLN dˇˇ ) ioSlot ° d ONLN dˇˇ )Q
SignedByte . ° d ONLN dˇˇ +8 Slot number ° d ONLN dˇˇ )6. . ° d ONLN dˇˇ ( £ äÆ ° d ONLN dˇˇ ) ioId ° d ONLN dˇˇ )Q
SignedByte . ° d ONLN dˇˇ +8 Slot r • ° d ONLN dˇˇ )esour Ì@ ° d ONLN dˇˇ )ce ID.
° d ONLN dˇˇ ( « ä Additional fi |0 ° d ONLN dˇˇ )4elds—multiple devices
° d ONLN dˇˇ ( ÷ äÆ . ° d ONLN dˇˇ ) ioMix ° d ONLN dˇˇ )QPtr . ° d ONLN dˇˇ )8!Reserved for use by driver Open r Ù@ ° d ONLN dˇˇ )ñoutine. ° d ONLN dˇˇ ( ‚ äÆ . ° d ONLN dˇˇ ) ioFlags ° d ONLN dˇˇ )QInteger . ° d ONLN dˇˇ )8!Determines number of additional fi ⁄@ ° d ONLN dˇˇ )úelds. ° d ONLN dˇˇ ( Ó äÆ . ° d ONLN dˇˇ )
ioSEBlkPtr ° d ONLN dˇˇ )QPtr . ° d ONLN dˇˇ )8$Pointer to external parameter block.
° d ONLN d H Å ( H DESCRIPTION
. ° d ONLN d ä& ü +BThe ° d ONLN d ü& œ )OpenSlot ° d ONLN d œ&W )0 function is equivalent to the ° d ONLN d 7W&{ )àPBOpen ° d ONLN d ={& )$# function, except that it sets the ° d ONLN d `' ä26 (/ ä%immediate bit (bit 9) of the trap wor R` ° d ONLN d Ö'62ô )¨d, which signals the R` ° d ONLN d ö&ô2∑ )c_Open R` ° d ONLN d ü'∑2æ ) r $¿ ° d ONLN d °'æ2 )outine that the . ° d ONLN d ±3 ä>2 (; ä%parameter block includes additional fi ∏` ° d ONLN d ◊32>F )®elds. ° d ONLN d ›B äM π (J ä
If the slot r 2 ° d ONLN d ÍB ∫M “ )0esour z@ ° d ONLN d ÔB “M )ce, which is defi ° d ONLN d BMˇ )G4ned in the chapter “The Slot Manager” in this book, ˇ˛√¬ . ° d ONLN d4N äYã (V ä=serves a single device, you should clear all the bits of the ˇ˝áÑ ≠ ° d ONLN dqMãYµ (VãioFlags ˇ˛√¬ ≠ ° d ONLN dxNµYΩ )* fi p⁄ ° d ONLN d{NæY ) eld and include the ° d ONLN dèZ äe Ì (b äslot number and slot r R` ° d ONLN d•Z Ìe )cesour $¿ ° d ONLN d™Ze> )
ce ID in the $¿ ° d ONLN d∑Y>eb ):ioSlot $¿ ° d ONLN dΩZbey )$ and $¿ ° d ONLN d¬Yyeë )ioID $¿ ° d ONLN dΔZëeõ ) fi $¿ ° d ONLN d…Zõe± )
elds. ° d ONLN dœi ät ¿ (q ä
If the slot r R` ° d ONLN d‹i ¿t ◊ )6esour $¿ ° d ONLN d·i ◊t≠ )/ce serves multiple devices, you should set the $¿ ° d ONLN dh≠t— )÷fMulti $¿ ° d ONLN di—t )$ bit of the ˇˇCê ° d ONLN d"t äÄ ¥ (} äioFlags ˇˇ°» ° d ONLN d)u ¥Ä ∫ )* f ÚH ° d ONLN d+u ∫Ää )0ield (clearing all other bits to 0), and specify ‰» ° d ONLN d[uâĨ )œ , in the ˇˇCê ° d ONLN ddt≠ÄÈ )$
ioSEBlkPtr ˇˇ°» ° d ONLN dnuÈÄÔ )< f <h ° d ONLN dpuÄ ) ield, an . ° d ONLN dyÅ äåÈ (â äSexternal parameter block that is customized for the devices installed in the slot. ° d ONLN dÕê äõÇ *7See the chapter “The Slot Manager” in this book for mor _† ° d ONLN dêÇõ® )¯
e details.
° d ONLN d∂ Hæ j (º HSPECIAL U ° d ONLN d∂ kæ ü )#
CONSIDERA Á ° d ONLN d ∂ ûæ ∏ )3TIONS
. ° d ONLN d&≈ ä– ü (Õ äThe ° d ONLN d*ƒ ü– œ )OpenSlot ° d ONLN d2≈ œ–‚ )0; function may move memory; you should not call it at interr l ° d ONLN dm≈‚– (Õ‚ upt time.
. ° d ONLN dwÎ HÛ n (Ò HASSEMBL ‹è ° d ONLN d~Î nÛ r )&Y ö∫ ° d ONLN dÎ sÛ – )-LANGUAGE INFORMA —U ° d ONLN dêÎ –Û Â )]TION
ˇˇ6= . ° d ONLN dï˙ ä ( ä
The trap macr æ⁄ ° d ONLN d¢˙ Ú )@
o for the ˇ˛lz aë ° d ONLN d¨˘ Û# ))OpenSlot ˇˇ6= aë ° d ONLN d¥˙#U )0
function is ˇ˛lz H ° d ONLN d¡˘Vt )3_Open ˇˇ6= H ° d ONLN dΔ˙t ) $ ($A200). The immediate bit (bit 9) . ° d ONLN dÍ ä à ( äof the trap wor o` ° d ONLN d˘ ø )BHd is set to signal to that the parameter block contains the additional fi U ° d ONLN dB˝ (˝elds. . ° d ONLN dH ä# ë ( äY ï ° d ONLN dI ê# ‘ )ou must setup r g` ° d ONLN dX ‘# ˆ )Degister ° d ONLN d` ˆ#I )"A0 with the addr €` ° d ONLN dpH#Á )R!ess of the parameter block. When €` ° d ONLN dëÁ# )ü_Open €` ° d ONLN dñ# ) . ° d ONLN dó$ ä/ ç (, är E ° d ONLN dò$ é/ ≥ ) eturns, r ° d ONLN d°$ ≥/ )%egister D0 contains the r Í¿ ° d ONLN d∫$ /∏ )j%esult code. Register D0 is the only r \Ä ° d ONLN dfl$π/· )ú
egister af Ä ° d ONLN dÈ$·/ )(
fected by ° d ONLN dÛ0 ä; † (8 äthis r ˛ ° d ONLN d˘0 †; æ )outine.
° d ONLN d? äJ ÿ (G äRegisters on entry
° d ONLN dN äY ñ *A0 ° d ONLN dN ΔY € )<addr |Ä ° d ONLN dN €YN )ess of the parameter block
° d ONLN d6] äh “ (e äRegisters on exit
° d ONLN dHl äw ñ *D0 ° d ONLN dKl Δw … )<r E ° d ONLN dLl w ˆ )
° d ONLN d ] * e D ( c *RESUL èU ° d ONLN d ] D e h )T CODES ,
Courier
. ° d ONLN d
k l w ä +(noErr . ° d ONLN d l ¯ w ˝ )å0 ° d ONLN d l w- )No err E† ° d ONLN d l. w7 ) or . ° d ONLN d v l Ç ® ( l
badUnitErr . ° d ONLN d ) w Ó Ç ˝ )Ç–21 ° d ONLN d - w Ç( )#Refer ⁄ ° d ONLN d 2 w( Ç” )&ence number out of range or not in use . ° d ONLN d Y Å l ç ¥ ( ä l unitEmptyErr . ° d ONLN d f Ç Ó ç ˝ )Ç–22 ° d ONLN d j Ç çÅ )#DCE points to null driver . ° d ONLN d Ñ å l ò ñ ( ï lopenErr . ° d ONLN d å ç Ó ò ˝ )Ç–23 ° d ONLN d ê ç òs )#Driver can’t perform r Y` ° d ONLN d ¶ çs ò≥ )b
equested open . ° d ONLN d ¥ ó l £ ú ( † ldInstErr . ° d ONLN d Ω ò Ó £ ˝ )Ç–26 ° d ONLN d ¡ ò £@ )#
Couldn’t fi Ä ° d ONLN d à òA £| )0nd driver in r ƒ† ° d ONLN d ⁄ ò| £î );esour ‡ ° d ONLN d fl òï £¶ )ce fi ”Ä ° d ONLN d ‰ ò¶ £≠ )le
° d ONLN d Á Ω * ≈ Q ( √ *SEE ALSO
° d ONLN d à l ◊ +B%For information about the low-level r Ɔ ° d ONLN d à ◊„ )§1outine for opening other device drivers, see the . ° d ONLN dF ÿ l „ v ( ‡ lpr R` ° d ONLN dH ÿ v „ )
$evious section, which describes the R` ° d ONLN dl ◊ „? )•PBOpen R` ° d ONLN dr ÿ? „F )$ r $¿ ° d ONLN dt ÿF „e )outine. . ° d ONLN d| Í l ı& ( Ú l)For an example of opening a device driver ±† ° d ONLN d• Í& ı; )∫, see ‡ ° d ONLN d´ Í< ıõ )Listing 1-1 on page 1- ¿ ° d ONLN d¡ Íõ ı† )_8 ¿ ° d ONLN d¬ ͆ ı¢ ).
° d ONLN du‰ lÔ r (Ï lY @Ä ° d ONLN dv‰ rÔí )Bou should not close drivers that other applications may be using, ° d ONLN d∏ l˚ ” (¯ lsuch as the Disk Driver œ@ ° d ONLN dœ “˚ Á )f, the Œ@ ° d ONLN d’ Á˚ )AppleT ÅÄ ° d ONLN d€˚i )!alk drivers, and so on.
u¿ ° d ONLN dˇˇ )es
ˇˇj® . ° d ONLN dˇ l
Ä ( lThe ˇ˛’P Í® ° d ONLN d ˛ Ä
¬ ) CloseDriver ˇˇj® Í® ° d ONLN dˇ ¬
° )B3 function is a high-level version of the low-level ˇ˛’P ™ê ° d ONLN dI˛¢
à )‡PBClose ˇˇj® ™ê ° d ONLN dPˇÃ
˜ )* function. ° d ONLN d[ l ì ( lUse the ° d ONLN dc
ì Ω )'PBClose ° d ONLN dj Ω¢ )*1 function when you want to specify a completion r R` ° d ONLN dõ ¢Í )Âoutine. See the ° d ONLN d´ l" ¡ ( ldescription of the ° d ONLN dæ ¡" Î )UPBClose ° d ONLN d≈ Î"" )*
function on , Times ° d ONLN d“""? )7page 1- ° d ONLN dŸ?"I ) 22 ° d ONLN d€I"L )
.
. ° d ONLN d›> *F L (D *SPECIAL U ° d ONLN d‰> MF Å )#
CONSIDERA Á ° d ONLN dÓ> ÄF ö )3TIONS
. ° d ONLN dÙL lW Å (T lThe ° d ONLN d¯K ÅW √ ) CloseDriver ° d ONLN dL √WÀ )B9 function does not move memory; you may call it at interr l ° d ONLN d<LÀWı (TÀ upt time.
. ° d ONLN dFs *{ D (y *RESUL èU ° d ONLN dKs D{ h )T CODES
. ° d ONLN dSÄ lå ä +(noErr . ° d ONLN dYÅ ¯å ˝ )å0 ° d ONLN d[Åå/ )No Err ó¿ ° d ONLN daÅ/å8 ) or . ° d ONLN ddã ló ® (î l
badUnitErr . ° d ONLN doå Óó ˝ )Ç–21 ° d ONLN dsåó( )#Refer ⁄ ° d ONLN dxå(ó” )&ence number out of range or not in use . ° d ONLN düñ l¢ ¥ (ü l unitEmptyErr . ° d ONLN d¨ó Ó¢ ˝ )Ç–22 ° d ONLN d∞ó¢Å )#DCE points to null driver . ° d ONLN d ° l≠ ® (™ l
notOpenErr . ° d ONLN d’¢ Ó≠ ˝ )Ç–26 ° d ONLN dŸ¢≠\ )#Driver isn’t open . ° d ONLN dΨ l∏ ú (µ labortErr . ° d ONLN dÙ≠ Ó∏ ˝ )Ç–27 ° d ONLN d¯≠∏/ )#Close r @Ä ° d ONLN dˇ≠0∏ú ) equest aborted by KillIO ˇ‰ @ ˇ ˇˇˇˇ @
ˇ·ˇ‚7^
4 H \ , Palatino
. +ä"CHAPTER œ´ )\1 , Helvetica
( @ äThe Device Manager 4⁄ ä˙ (‡ ä Reference to the Device Manager
° d ONLN d l ä w. +B%For information about the low-level r Ɔ ° d ONLN d . l. w˜ )§0outine for closing device drivers, see the next . ° d ONLN d ^ x ä É ( Ä ä section, which describes the ,
Courier ° d ONLN d { w É9 )ÖPBClose ° d ONLN d Ç x9 Éc )*
function.
≥ H ª 4 ¥ H ª ¥ H ¥
ˇ·ˇ‚7^
. ° d ONLN d é ¶ H ≥ u ( ∞ HPBClose ˇˇˇˇˇˇ ( ∞1
. ° d ONLN d ñ Δ ä — ë ( Œ äY ï ° d ONLN d ó Δ ê — ” )ou can use the ï ° d ONLN d ¶ ≈ ” — ˝ )CPBClose ï ° d ONLN d ≠ Δ ˝ —∞ )*( function to close an open device driver ◊† ° d ONLN d ’ ΔØ —≤ )≤. ° d ONLN d ◊ › ä È Í ( Ê äFUNCTION PBClose ° d ONLN d Ô › Í È )` ° d ONLN d › ÈÄ )(paramBlock: ParmBlkPtr; ° d ONLN d Î ‰ ˜ Í ( Ù ‰ ° d ONLN d Î Í ˜ ) ° d ONLN d Î ˜ ˆ ) ° d ONLN d Î ˆ ˜Ä )async: Boolean): OSErr; ° d ONLN d, ä Δ ( ä
paramBlock . ° d ONLN d7 ÃÜ )B*Contains a pointer to the parameter block. . ° d ONLN db ä ® ( äasync . ° d ONLN dh Ã È )BSpecifi ‡ ° d ONLN do È ñ ) &es to the Device Manager whether the r RÄ ° d ONLN dïó ‚ )Æequest is asynchr Œ‡ ° d ONLN d¶‚ )Konous. ° d ONLN dÆ& ä1 ê (. äY @Ä ° d ONLN dØ& ê1 ˆ )ou specify values and r P ° d ONLN dΔ& ˆ1 )feceive r ¿ ° d ONLN dŒ&1¯ )!1eturn values in a Device Manager parameter block.
> HN 4? HM
° d ONLN dˇˇ (F äParameter block
ˇ·ˇ‚7^ , Symbol
° d ONLN dˇˇ *Æ . ° d ONLN dˇˇ ) ioCompletion ° d ONLN dˇˇ )QProcPtr . ° d ONLN dˇˇ )8Pointer to completion r ì‡ ° d ONLN dˇˇ )foutine. ° d ONLN dˇˇ (` ä¨ . ° d ONLN dˇˇ ) ioResult ° d ONLN dˇˇ )QOSErr . ° d ONLN dˇˇ )8 Result code. ° d ONLN dˇˇ (l äÆ . ° d ONLN dˇˇ ) ioRefNum ° d ONLN dˇˇ )QInteger . ° d ONLN dˇˇ )8Driver r ø¿ ° d ONLN dˇˇ )#efer k‡ ° d ONLN dˇˇ ) ence number Û¿ ° d ONLN dˇˇ )8.
° d ONLN dßã Hì Å (ë H DESCRIPTION
. ° d ONLN d≥ô ä§ ü +BThe ° d ONLN d∑ò ü§ … )PBClose ° d ONLN dæô …§Ç )*) function closes the device driver specifi ° d ONLN dËôǧ± )π
ed by the ° d ONLN dÚò±§· )/ioRefNum ° d ONLN d˙ô·§Î )0 fi ° d ONLN d˝ôΧ )
° d ONLN dk’ ä‡ ê (› äY @Ä ° d ONLN dl’ ê‡∞ )Bou should not close drivers that other applications may be using, ° d ONLN dÆ· äÏ Ò (È äsuch as the Disk Driver œ@ ° d ONLN d≈· Ï )f, the Œ@ ° d ONLN dÀ·Ï& )AppleT ÅÄ ° d ONLN d—·&Ïá )!alk drivers, and so on.
u¿ ° d ONLN dˇˇ )es
° d ONLN d˝ ä˚ ≈ (¯ äIf the driver r Æ ° d ONLN d ≈˚ );eturns a negative r À‡ ° d ONLN d ˚= )R
esult in r É ° d ONLN d)>˚Œ )' egister D0, the Device Manager r @‡ ° d ONLN dIœ˚ )ë eturns this . ° d ONLN dU¸ ä é ( är R` ° d ONLN dV¸ é › )esult code in the R` ° d ONLN dh˚ ›
)OioResult R` ° d ONLN dp¸
» )0( parameter and does not close the driver ï ° d ONLN dò¸« )∫.
. ° d ONLN dö" H* j (( HSPECIAL U ° d ONLN d°" k* ü )#
CONSIDERA Á ° d ONLN d´" û* ∏ )3TIONS
. ° d ONLN d±1 ä< ü (9 äThe ° d ONLN dµ0 ü< … )PBClose ° d ONLN dº1 …<— )*9 function does not move memory; you may call it at interr l ° d ONLN dı1—<˚ (9— upt time.
. ° d ONLN dˇW H_ n (] HASSEMBL ‹è ° d ONLN dW n_ r )&Y ö∫ ° d ONLN dW s_ – )-LANGUAGE INFORMA —U ° d ONLN dW –_ Â )]TION
ˇˇ\ . ° d ONLN d f äq (n ä
The trap macr ] ° d ONLN d*f q Ú )@
o for the ˇ˛
∏ m, ° d ONLN d4e Úq )(PBClose ˇˇ\ m, ° d ONLN d;f qN )*
function is ˇ˛
∏ }@ ° d ONLN dHeNqr )2_Close ˇˇ\ }@ ° d ONLN dNfrq )$$ ($A001). Set bit 10 of the trap wor zÄ ° d ONLN drfq )úd . ° d ONLN dtr ä} œ (z äto execute this r ı@ ° d ONLN dÖr œ} )Eoutine asynchr [¿ ° d ONLN dìr}4 )Bonously ∏ ° d ONLN dör3}Õ )"%. Set bit 9 to execute it immediately ù‡ ° d ONLN dørÃ}Œ )ô. . ° d ONLN d¡Ñ äè ë (å äY ï ° d ONLN d¬Ñ êè ‘ )ou must setup r g` ° d ONLN d—Ñ ‘è ˆ )Degister ° d ONLN dŸÑ ˆèI )"A0 with the addr €` ° d ONLN dÈÑHèÁ )R!ess of the parameter block. When €` ° d ONLN d
ÉÁè )ü_Close €` ° d ONLN dÑ è )$ . ° d ONLN dê äõ ç (ò är E ° d ONLN dê éõ ≥ ) eturns, r ° d ONLN dê ≥õ )%egister D0 contains the r Í¿ ° d ONLN d4ê õ∏ )j%esult code. Register D0 is the only r \Ä ° d ONLN dYêπõ· )ú
egister af Ä ° d ONLN dcê·õ )(
fected by ° d ONLN dmú äß † (§ äthis r ˛ ° d ONLN dsú †ß æ )outine. ˇt @ ˇ ˇˇˇˇ @
° d ONLN d k l v x *A0 ° d ONLN d k ® v Ω )<addr |Ä ° d ONLN d k Ω v0 )ess of the parameter block
° d ONLN d 5 z l Ö ¥ ( Ç lRegisters on exit
° d ONLN d G â l î x *D0 ° d ONLN d J â ® î ´ )<r E ° d ONLN d K â ¨ î ÿ )
esult code
° d ONLN d V Ø * ∑ D ( µ *RESUL èU ° d ONLN d [ Ø D ∑ h )T CODES ,
Courier
. ° d ONLN d c Ω l … ä +(noErr . ° d ONLN d i æ ¯ … ˝ )å0 ° d ONLN d k æ …/ )No Err ó¿ ° d ONLN d q æ/ …8 ) or . ° d ONLN d t » l ‘ ® ( — l
badUnitErr . ° d ONLN d … Ó ‘ ˝ )Ç–21 ° d ONLN d É … ‘( )#Refer ⁄ ° d ONLN d à …( ‘” )&ence number out of range or not in use . ° d ONLN d Ø ” l fl ¥ ( ‹ l unitEmptyErr . ° d ONLN d º ‘ Ó fl ˝ )Ç–22 ° d ONLN d ¿ ‘ flÅ )#DCE points to null driver . ° d ONLN d ⁄ fi l Í ® ( Á l
notOpenErr . ° d ONLN d  fl Ó Í ˝ )Ç–26 ° d ONLN d È fl Í\ )#Driver isn’t open . ° d ONLN d ˚ È l ı ú ( Ú labortErr . ° d ONLN d Í Ó ı ˝ )Ç–27 ° d ONLN d Í ı/ )#Close r @Ä ° d ONLN d Í0 ıú ) equest aborted by KillIO
° d ONLN d( * Q ( *SEE ALSO
° d ONLN d1 l) +B&For information about the high-level r ° d ONLN dW )“ )®-outine for closing device drivers, see the pr @ ° d ONLN dÑ “)Ò )æevious . ° d ONLN dã* l5 Ò (2 l section, which describes the ° d ONLN d®) Ò53 )Ö CloseDriver ° d ONLN d≥*35] )B
function.
Y *a¯ 4Z *a¯ Z *Z˛
ˇ·ˇ‚7^
. ° d ONLN dæL *Y d (V *
Reading Fr Ì@ ° d ONLN d»L dY õ ):om and W ~¿ ° d ONLN d–L õY ¬ )7riting T ¿ ° d ONLN dÿL ¬Y ı )' o Devices ˇˇˇˇˇˇ (VÚ1
. ° d ONLN d‚b lm s (j lY ï ° d ONLN d„b rm ’ )ou can use either the ï ° d ONLN d˘a ’m ˘ )cFSRead ï ° d ONLN dˇb ˘m )$ or ï ° d ONLN dam, )PBRead ï ° d ONLN d b,mf )$ function to r g` ° d ONLN dbfmª ):ead information fr 9¿ ° d ONLN d)bªmı )U om a device ° d ONLN d5n ly È (v ldriver and you can use the ° d ONLN dPm Èy )}FSWrite ° d ONLN dWny" )* or ° d ONLN d[m"yL )PBWrite ° d ONLN dbnLyÏ )*$ function to write information to a . ° d ONLN dÜz lÖ ¶ (Ç l
device driver I¿ ° d ONLN dìz ¶Ö ® ):. . ° d ONLN dïå ló Å (î lThe ° d ONLN dôã Åó • )PBRead ° d ONLN düå •ó º )$ and ° d ONLN d§ã ºó Ê )PBWrite ° d ONLN d´å Êóà )*# functions use the additional I/O fi ° d ONLN dœåàó )¢elds of the parameter . ° d ONLN dÂò l£ œ († lblock, as described on C` ° d ONLN d¸ò –£ )dpage 1- r ° d ONLN dò £ ˙ ) 15 r ° d ONLN dò ˙£ ¸ )
.
” *€¯ 4‘ *€¯ ‘ *‘˛
ˇ·ˇ‚7^
° d ONLN dΔ *” S (– *FSRead ˇˇˇˇˇˇ (–Ú1
. ° d ONLN dÊ lÒ s (Ó lY ï ° d ONLN dÊ rÒ µ )ou can use the ï ° d ONLN d  µÒ Ÿ )CFSRead ï ° d ONLN d%Ê ŸÒ )$ function to r g` ° d ONLN d3ÊÒH ): ead data fr 9¿ ° d ONLN d>ÊHÒ„ )5!om an open driver into a data buf ° d ONLN d_Ê„Ò )õfer N¿ ° d ONLN dbÊÔÒÚ ) . ° d ONLN dd˝ l Δ ( lFUNCTION FSRead ° d ONLN d{˝ Δ Ã )Z ° d ONLN d|˝ à ™ )%(refNum: Integer; VAR count: LongInt; ° d ONLN d™ Δ Ã ( Δ ° d ONLN d´ à “ ) ° d ONLN d¨ “P )buffPtr: Ptr): OSErr; ° d ONLN d¬# l/ ê (, lrefNum . ° d ONLN d…$ Æ/ À )BSpecifi ‡ ° d ONLN d–$ À/ Í ) es the r ô‡ ° d ONLN dÿ$ Î/ ˚ ) efer F ° d ONLN d‹$ ¸/n )ence number of the driver M‡ ° d ONLN dı$n/p )r. . ° d ONLN d˜3 l? ä (< lcount . ° d ONLN d˝4 Æ?B )B"Indicates the number of bytes to r · ° d ONLN d 4B?T )îead. . ° d ONLN d$C lO ñ (L lbuffPtr . ° d ONLN d,D ÆO )BPoints to a data buf @ ° d ONLN d@DOZ )Vfer to hold the data.
° d ONLN dVj *r c (p * DESCRIPTION
ˇ˛® . ° d ONLN dby lÑ Ö +BBefor R` ° d ONLN dgy ÖÑ æ )e calling the ˇ˝P" Jì ° d ONLN dux øÑ „ ):FSRead ˇ˛® Jì ° d ONLN d{y „Ñ– )$6 function, your application should allocate a data buf ]{ ° d ONLN d±y–ÑÏ )Ìfer lar ◊Ï ° d ONLN d∏yÏј ) ge ˇˇ\ ° d ONLN dªÖ lê ˆ (ç l enough to hold the data to be r w‰ ° d ONLN d⁄Ö ˆê )ä ead. The ˇ˛
∏ Çú ° d ONLN d„Ñ êD )*FSRead ˇˇ\ Çú ° d ONLN dÈÖDê¶ )$ function attempts to r jl ° d ONLN d Ö¶ê¯ )bead the number of ˇˇ`÷ ° d ONLN dë lú ‘ (ô lbytes indicated by the ˇ˛¡¨ X ° d ONLN d)ê ’ú Û )icount ˇˇ`÷ X ° d ONLN d.ë Ûú/ )
° d ONLN d h ä s • ( p äBe sur ÓÄ ° d ONLN d h • s “ )
e your buf kÄ ° d ONLN d h ” s ˜ ).
fer is lar N` ° d ONLN d h ˜ s§ )$&ge enough to hold the number of bytes . ° d ONLN d @ t ä ® ( | äspecifi ° d ONLN d G t ® ◊ )
ed by the ,
Courier ° d ONLN d Q s ◊ ı )/count ° d ONLN d V t ı ( )
parameter ¬† ° d ONLN d ` t' û )2, or this function may corr Ɔ ° d ONLN d { tû ∞ )wupt . ° d ONLN d Ä ä ã Ø ( à ämemory Õ ° d ONLN d Ö Ä Æ ã ≥ )$.
. ° d ONLN dØ › H  j ( „ HSPECIAL U ° d ONLN d∂ › k  ü )#
CONSIDERA Á ° d ONLN d¿ › û Â ∏ )3TIONS
. ° d ONLN dΔ Î ä ˆ ü ( Û äThe ° d ONLN d Í ü ˆ √ )FSRead ° d ONLN d– Î √ ˆT )$ function does not move memory d@ ° d ONLN dÓ ÎS ˆÉ )ê . However ¶‡ ° d ONLN d˜ ÎÇ ˆ◊ )/, you should be sur y@ ° d ONLN d
Î◊ ˆ )U
e the device . ° d ONLN d ˜ ä" ( ˇ ä driver does not move memory in r õ` ° d ONLN d7 ˜"^ )òesponse to a r ÓÄ ° d ONLN dE ˜^t )<ead r ‡ ° d ONLN dJ ˜u´ ) equest befor +` ° d ONLN dV ˜´ )6e you call this function ° d ONLN do ä ≠ ( ä at interr Ÿ` ° d ONLN dx ≠ ’ )# upt time.
° d ONLN dÇ* H2 b (0 HRESUL èU ° d ONLN dá* b2 Ü )T CODES
. ° d ONLN dè7 äC ® +(noErr . ° d ONLN dï8C )å0 ° d ONLN dó8/CM )No Err ó¿ ° d ONLN dù8MCV ) or . ° d ONLN d†B äN ¥ (K äreadErr . ° d ONLN d®C N )Ç–19 ° d ONLN d¨C/Nj )#Driver can’t r ã ° d ONLN d∫CjNú ); espond to r s@ ° d ONLN d≈CúN≤ )2ead r ù† ° d ONLN d C≤N“ )equests . ° d ONLN d“M äY Δ (V ä
badUnitErr . ° d ONLN d›N Y )Ç–21 ° d ONLN d·N/YF )#Refer ⁄ ° d ONLN dÊNFYÒ )&ence number out of range or not in use . ° d ONLN d
X äd “ (a ä unitEmptyErr . ° d ONLN dY d )Ç–22 ° d ONLN d Y/dü )#DCE points to null driver . ° d ONLN d8c äo Δ (l ä
notOpenErr . ° d ONLN dCd o )Ç–26 ° d ONLN dGd/oz )#Driver isn’t open . ° d ONLN dYn äz ∫ (w äabortErr . ° d ONLN dbo z )Ç–27 ° d ONLN dfo/zï )#Read aborted by KillIO
° d ONLN d}ï Hù o (õ HSEE ALSO
° d ONLN dÜ£ äÆ. +B%For information about the low-level r Ɔ ° d ONLN d´£.Æ_ )§ outine for r r ° d ONLN d∑£`Æá )2 eading fr 9 ° d ONLN d¿£àÆ )( om device drivers, see the next . ° d ONLN d‡Ø ä∫ (∑ ä section, which describes the ° d ONLN d˝Æ∫3 )ÖPBRead ° d ONLN dØ3∫] )$
function.
Î HÛ 4Î HÚ Î HÎ
ˇ·ˇ‚7^
. ° d ONLN d› HÍ s (Á HPBRead ˇˇˇˇˇˇ (Á1
. ° d ONLN d˝ ä ë ( äY ï ° d ONLN d˝ ê ” )ou can use the ï ° d ONLN d&¸ ” ˜ )CPBRead ï ° d ONLN d,˝ ˜1 )$ function to r g` ° d ONLN d:˝1f ): ead data fr 9¿ ° d ONLN dE˝f )5!om an open driver into a data buf ° d ONLN df˝ )õfer N¿ ° d ONLN di˝
) . ° d ONLN dk ä ‰ ( äFUNCTION PBRead ° d ONLN dÇ ‰ Í )Z ° d ONLN dÉ Í )1(paramBlock: ParmBlkPtr; async: Boolean) : OSErr; ° d ONLN dµ, ä8 Δ (5 ä
paramBlock . ° d ONLN d¿- Ã8Ü )B*Contains a pointer to the parameter block. . ° d ONLN dÎ< äH ® (E äasync . ° d ONLN dÒ= ÃH È )BSpecifi ‡ ° d ONLN d¯= ÈHñ ) &es to the Device Manager whether the r RÄ ° d ONLN d =óH‚ )Æequest is asynchr Œ‡ ° d ONLN d/=‚H )Konous. ˇ ¸ @ ˇ ˇˇˇˇ @
° d ONLN d ] l h r ( e lY @Ä ° d ONLN d ] r h ÿ )ou specify values and r P ° d ONLN d ] ÿ h ˘ )feceive r ¿ ° d ONLN d ] ˘ h⁄ )!1eturn values in a Device Manager parameter block.
t * ѯ 4 u * ɯ
° d ONLN dˇˇ ( | lParameter block
ˇ·ˇ‚7^ , Symbol
° d ONLN dˇˇ *Æ ,
Courier . ° d ONLN dˇˇ ) ioCompletion ° d ONLN dˇˇ )QProcPtr . ° d ONLN dˇˇ )8Pointer to completion r ì‡ ° d ONLN dˇˇ )foutine. ° d ONLN dˇˇ ( ñ l¨ . ° d ONLN dˇˇ ) ioResult ° d ONLN dˇˇ )QOSErr . ° d ONLN dˇˇ )8 Result code. ° d ONLN dˇˇ ( ¢ lÆ . ° d ONLN dˇˇ ) ioVRefNum ° d ONLN dˇˇ )QInteger . ° d ONLN dˇˇ )8 Drive number ; ° d ONLN dˇˇ )>. ° d ONLN dˇˇ ( Æ lÆ . ° d ONLN dˇˇ ) ioRefNum ° d ONLN dˇˇ )QInteger . ° d ONLN dˇˇ )8Driver r ø¿ ° d ONLN dˇˇ )#efer k‡ ° d ONLN dˇˇ ) ence number Û¿ ° d ONLN dˇˇ )8. ° d ONLN dˇˇ ( ∫ lÆ . ° d ONLN dˇˇ ) ioBuffer ° d ONLN dˇˇ )QPtr . ° d ONLN dˇˇ )8Pointer to data buf Ä ° d ONLN dˇˇ )Sfer U@ ° d ONLN dˇˇ ) . ° d ONLN dˇˇ ( Δ lÆ . ° d ONLN dˇˇ )
ioReqCount ° d ONLN dˇˇ )QLongInt . ° d ONLN dˇˇ )8 Requested number of bytes to r ‹† ° d ONLN dˇˇ )äead. ° d ONLN dˇˇ ( “ l¨ . ° d ONLN dˇˇ )
ioActCount ° d ONLN dˇˇ )QLongInt . ° d ONLN dˇˇ )8Actual number of bytes r «‡ ° d ONLN dˇˇ )nead. ° d ONLN dˇˇ ( fi lÆ . ° d ONLN dˇˇ ) ioPosMode ° d ONLN dˇˇ )QInteger . ° d ONLN dˇˇ )8Positioning mode. ° d ONLN dˇˇ ( Í l´ . ° d ONLN dˇˇ ) ioPosOffset ° d ONLN dˇˇ )QLongInt . ° d ONLN dˇˇ )8Positioning of ˙¿ ° d ONLN dˇˇ )=fset.
° d ONLN dJ * c ( * DESCRIPTION
ˇ˛® . ° d ONLN dV l" Ö +BBefor R` ° d ONLN d[ Ö" æ )e calling the ˇ˝P" Jì ° d ONLN di ø" „ ):PBRead ˇ˛® Jì ° d ONLN do „"– )$6 function, your application should allocate a data buf ]{ ° d ONLN d•–"Ï )Ìfer lar ◊Ï ° d ONLN d¨Ï"˜ ) ge ˇˇ\ ° d ONLN dØ# l. ˆ (+ l enough to hold the data to be r w‰ ° d ONLN dŒ# ˆ. )ä ead. The ˇ˛
∏ Çú ° d ONLN d◊" .D )*PBRead ˇˇ\ Çú ° d ONLN d›#D.¶ )$ function attempts to r jl ° d ONLN dÙ#¶.¯ )bead the number of ˇˇ>ï ° d ONLN d/ l: ” (7 lbytes indicated by the ˇ˛}* zT ° d ONLN d . ‘: )h
ioReqCount ˇˇ>ï zT ° d ONLN d'/: )< fi ∏È ° d ONLN d*/:2 ) eld fr …fi ° d ONLN d0/2:q )
om the specifi G ° d ONLN d>/r:¯ )@ ed device driver and transfer ˇ˛º ° d ONLN d\; lF (C lthem to this data buf B¿ ° d ONLN dq; ÀF ÿ )_fer Ö` ° d ONLN dt; ◊F € ) . „ ° d ONLN dv; €Fv )$After the transfer is complete, the ˇ˝x0 K® ° d ONLN dö:wF≥ )ú
ioActCount ˇ˛º K® ° d ONLN d§;≥Fª )< fi ¿ ° d ONLN dß;ºF¯ ) eld indicates . ° d ONLN dµG lR (O l the number of bytes actually r ’Ä ° d ONLN d”G R )Ñead.
` *l¯ 4` *l¯ ,
Zapf Dingbats
° d ONLN dˇˇ (g Xs
° d ONLN dˇˇ )W †F ° d ONLN dˇˇ )ARNING
ˇ·ˇ‚7^
° d ONLN dÿk lv á (s lBe sur ÓÄ ° d ONLN dfik áv ¥ )
e your buf kÄ ° d ONLN dËk µv Ÿ ).
fer is lar N` ° d ONLN dÚk ŸvÜ )$&ge enough to hold the number of bytes . ° d ONLN dw lÇ ä ( lspecifi ° d ONLN d w äÇ π )
ed by the ° d ONLN d)v πÇ ◊ )/count ° d ONLN d.w ◊Ç
)
parameter ¬† ° d ONLN d8w ÇÄ )2, or this function may corr Ɔ ° d ONLN dSwÄÇí )wupt . ° d ONLN dWÉ lé ë (ã lmemory Õ ° d ONLN d]É êé ï )$.
)eld and specify a positioning mode and of R` ° d ONLN d°Ø¨‚ )¡ fset in the ° d ONLN d ¨ l∏ ¢ (µ l ioPosMode ° d ONLN d&≠ ¢∏ π )6 and ° d ONLN d+¨ π∏ ˚ ) ioPosOffset ° d ONLN d6≠ ˚∏ )B f PÄ ° d ONLN d8≠∏ )ields. PÄ ° d ONLN d?≠ ∏x ) Bits 0 and 1 of the PÄ ° d ONLN dS¨x∏Æ )Y ioPosMode PÄ ° d ONLN d\≠Æ∏µ )6 f ! ° d ONLN d^≠µ∏Ù )ield indicate . ° d ONLN dlπ lƒ Ç (¡ lwher 7 ° d ONLN dpπ Ƀ ) e an operation should begin r ¿ ° d ONLN dçπƒÃ )Å/elative to the physical beginning of the block- ° d ONLN dº≈ l– ƒ (Õ lformatted medium. I` ° d ONLN dŒ≈ ≈– À )YY ‡ ° d ONLN dœ≈ À–Ì )Eou can use the following constants to test or set the value of these ° d ONLN d— l‹ ~ (Ÿ lbits: . ° d ONLN d Ë lÙ Δ *CONST fsAtMark ° d ONLN d+Ë ΔÙ “ )Z ° d ONLN d-Ë “Ù ) = 0; ° d ONLN d3Ë Ùn ) {at current position} ° d ONLN dIˆ l r (ˇ l ° d ONLN dJˆ r x ) ° d ONLN dKˆ x ~ ) ° d ONLN dLˆ ~ Ñ ) ° d ONLN dMˆ Ñ ä ) ° d ONLN dNˆ ä ê ) ° d ONLN dOˆ ê fi )
fsFromStart= ° d ONLN d\ˆ fi Í )N1; ° d ONLN d_ˆ Íz ) {offset from beginning} ° d ONLN dx l r (
l ° d ONLN dy r x ) ° d ONLN dz x ~ ) ° d ONLN d{ ~ Ñ ) ° d ONLN d| Ñ ä ) ° d ONLN d} ä ê ) ° d ONLN d~ ê “ ) fsFromMark ° d ONLN dâ “ Í )B= 2; ° d ONLN dé ͧ ) {offset from current position} . ° d ONLN dÆ l( (% l$After the transfer is complete, the «@ ° d ONLN d“ (4 )ñ ioPosOffset ≠‡ ° d ONLN d› 5(= )3 fi :† ° d ONLN d‡ >(ö ) eld indicates the curr ‡ ° d ONLN dˆ õ(Ì )]ent position of the ° d ONLN d
° d ONLN d ] H e j ( c HSPECIAL U ° d ONLN d ] k e ü )#
CONSIDERA Á ° d ONLN d ] û e ∏ )3TIONS
. ° d ONLN d l ä w ü ( t äThe ,
Courier ° d ONLN d k ü w √ )PBRead ° d ONLN d ! l √ wT )$ function does not move memory d@ ° d ONLN d ? lS wÉ )ê . However ¶‡ ° d ONLN d H lÇ w◊ )/, you should be sur y@ ° d ONLN d [ l◊ w )U
e the device . ° d ONLN d h x ä É" ( Ä ä driver does not move memory in r õ` ° d ONLN d à x" É^ )òesponse to a r ÓÄ ° d ONLN d ñ x^ Ét )<ead r ‡ ° d ONLN d õ xu É´ ) equest befor +` ° d ONLN d ß x´ É )6e you call this function ° d ONLN d ¿ Ñ ä è ≠ ( å ä at interr Ÿ` ° d ONLN d … Ñ ≠ è ’ )# upt time.
° d ONLN d ” ™ H ≤ n ( ∞ HASSEMBL ‹è ° d ONLN d ⁄ ™ n ≤ r )&Y ö∫ ° d ONLN d € ™ s ≤ – )-LANGUAGE INFORMA —U ° d ONLN d Ï ™ – ≤ Â )]TION
ˇˇH . ° d ONLN d Ò π ä ƒ ( ¡ ä
The trap macr x ° d ONLN d ˛ π ƒ Ú )@
o for the ˇ˛&ê ≤» ° d ONLN d ∏ Ú ƒ )(PBRead ˇˇH ≤» ° d ONLN d π ƒH )$
function is ˇ˛&ê φ ° d ONLN d ∏H ƒf )2_Read ˇˇH φ ° d ONLN d πf ƒ ) $ ($A002). Set bit 10 of the trap wor Y@ ° d ONLN dD π ƒ )ùd to . ° d ONLN dI ≈ ä – ƒ ( Õ äexecute this r Ω` ° d ONLN dW ≈ ƒ – ):outine asynchr #‡ ° d ONLN de ≈ –) )Bonously Ä ° d ONLN dl ≈( –¬ )"%. Set bit 9 to execute it immediately f ° d ONLN dë ≈¡ –√ )ô. . ° d ONLN dì ◊ ä ‚ ë ( fl äY ï ° d ONLN dî ◊ ê ‚ ‘ )ou must setup r g` ° d ONLN d£ ◊ ‘ ‚ ˆ )Degister ° d ONLN d´ ◊ ˆ ‚I )"A0 with the addr €` ° d ONLN dª ◊H ‚Á )R!ess of the parameter block. When €` ° d ONLN d‹ ÷Á ‚ )ü_Read €` ° d ONLN d· ◊ ‚ ) . ° d ONLN d‚ „ ä Ó ç ( Î är E ° d ONLN d„ „ é Ó ≥ ) eturns, r ° d ONLN dÏ „ ≥ Ó )%egister D0 contains the r Í¿ ° d ONLN d „ Ó∏ )j%esult code. Register D0 is the only r \Ä ° d ONLN d* „π Ó· )ú
egister af Ä ° d ONLN d4 „· Ó )(
fected by ° d ONLN d> Ô ä ˙ † ( ˜ äthis r ˛ ° d ONLN dD Ô † ˙ æ )outine.
° d ONLN dL ˛ ä ÿ ( äRegisters on entry
° d ONLN d_
ä ñ *A0 ° d ONLN db
Δ € )<addr |Ä ° d ONLN df
€N )ess of the parameter block
° d ONLN dÅ ä' “ ($ äRegisters on exit
° d ONLN dì+ ä6 ñ *D0 ° d ONLN dñ+ Δ6 … )<r E ° d ONLN dó+ 6 ˆ )
esult code
° d ONLN d¢Q HY b (W HRESUL èU ° d ONLN dßQ bY Ü )T CODES
. ° d ONLN dØ_ äk ® +(noErr . ° d ONLN dµ`k )å0 ° d ONLN d∑`/kK )No err E† ° d ONLN dΩ`LkU ) or . ° d ONLN d¿j äv ¥ (s äreadErr . ° d ONLN d»k v )Ç–19 ° d ONLN dÃk/vj )#Driver can’t r ã ° d ONLN d⁄kjvú ); espond to r s@ ° d ONLN dÂkúv≤ )2ead r ù† ° d ONLN dÍk≤v“ )equests . ° d ONLN dÚu äÅ Δ (~ ä
badUnitErr . ° d ONLN d˝v Å )Ç–21 ° d ONLN dv/ÅF )#Refer ⁄ ° d ONLN dvFÅÒ )&ence number out of range or not in use . ° d ONLN d-Ä äå “ (â ä unitEmptyErr . ° d ONLN d:Å å )Ç–22 ° d ONLN d>Å/åü )#DCE points to null driver . ° d ONLN dXã äó Δ (î ä
notOpenErr ° d ONLN dcå ó )Ç–26 . ° d ONLN dgå/óz )#Driver isn’t open . ° d ONLN dyñ ä¢ ∫ (ü äabortErr . ° d ONLN dÇó ¢ )Ç–27 ° d ONLN dÜó/¢ï )#Read aborted by KillIO . ° d ONLN dù° ä≠ ® (™ äioErr ° d ONLN d£¢ ≠ )Ç–36 . ° d ONLN dߢ/≠ñ )#Data doesn’t match in r …@ ° d ONLN dæ¢ñ≠fl )gead-verify mode
° d ONLN dŒ« Hœ o (Õ HSEE ALSO
° d ONLN d◊÷ ä·1 +B&For information about the high-level r ° d ONLN d˝÷2·c )® outine for r ◊` ° d ONLN d ÷c·ä )1 eading fr ûÄ ° d ONLN d÷ã· )(om device drivers, see the . ° d ONLN d-‚ äÌ î (Í äpr R` ° d ONLN d/‚ îÌ9 )
$evious section, which describes the R` ° d ONLN dS·9Ì] )•FSRead R` ° d ONLN dY‚]Ìä )$ function.
, H4 4- H4 - H-
ˇ·ˇ‚7^
. ° d ONLN df H, b () HFSW ù ° d ONLN di a, s )rite ˇˇˇˇˇˇ ()1
. ° d ONLN dn? äJ ë (G äY ï ° d ONLN do? êJ ” )ou can use the ï ° d ONLN d~> ”J ˝ )CFSWrite ï ° d ONLN dÖ? ˝Jp )* function to write data fr g` ° d ONLN dü?pJ∞ )s
om a data buf 9¿ ° d ONLN d¨?∞J )@fer to an open driver |` ° d ONLN d¡?J )^. ° d ONLN d√V äb Í (_ äFUNCTION FSWrite ° d ONLN d€V Íb )` ° d ONLN d‹V bŒ )%(refNum: Integer; VAR count: LongInt; ° d ONLN d
d ‰p Í (m ‰ ° d ONLN d d Íp ) ° d ONLN d d p ˆ ) ° d ONLN d
d ˆpz )buffPtr: Ptr) : OSErr; ° d ONLN d$| äà Æ (Ö ärefNum . ° d ONLN d+} Ãà È )BSpecifi ‡ ° d ONLN d2} Èà ) es the r ô‡ ° d ONLN d:} à ) efer F ° d ONLN d>}àå )ence number of the driver M‡ ° d ONLN dW}åàé )r. . ° d ONLN dYå äò ® (ï äcount . ° d ONLN d_ç Ãòv )B'Indicates the number of bytes to write. . ° d ONLN dáú ä® ¥ (• äbuffPtr . ° d ONLN dèù î* )BPoints to the data buf ‡† ° d ONLN d•ù*®ç )^fer that holds the data. ˇä @ ˇ ˇˇˇˇ @
Courier ° d ONLN d k Å w ´ )FSWrite ° d ONLN d l ´ w÷ )*A function attempts to write the number of bytes indicated by the ° d ONLN d X k÷ wÙ ( t÷count ° d ONLN d ] lÙ w˜ ) ˇˇÜÉ ° d ONLN d ^ x l É ¶ ( Ä l parameter fr ÿ„ ° d ONLN d j x ¶ É Ó ):om the data buf >à ° d ONLN d y x Ô ÉO )Ifer pointed to by the ˇˇ
fl[ ° d ONLN d è wO Éy )`buffPtr ˇˇÜÉ fl[ ° d ONLN d ñ xy ÉÍ )* parameter to the specifi ˘g ° d ONLN d Ø xÍ É˜ )qed ˇ˛≥] ° d ONLN d ≤ Ñ l è ® ( å l
device driver u˝ ° d ONLN d ø Ñ ® è ¨ )<. ˙ ° d ONLN d ¡ Ñ ¨ èG )$After the transfer is complete, the ˇ˝f∫ ˇ( ° d ONLN d  ÉG èe )õcount ˇ˛≥] ˇ( ° d ONLN d Í Ñe è˜ ) parameter indicates the number . ° d ONLN d
. ° d ONLN dU È * Ò L ( Ô *SPECIAL U ° d ONLN d\ È M Ò Å )#
CONSIDERA Á ° d ONLN df È Ä Ò ö )3TIONS
ˇˇ…† . ° d ONLN dl ¯ l Ä ( lThe ˇˇì@ I† ° d ONLN dp ˜ Å ´ )FSWrite ˇˇ…† I† ° d ONLN dw ¯ ´: )* function does not move memory ° d ONLN dï ¯:i )è . However *@ ° d ONLN dû ¯iΩ )/, you should be sur # ° d ONLN d± ¯Ω¯ )T
e the device . ° d ONLN dæ l ( l driver does not move memory in r õ` ° d ONLN dfiZ )òesponse to a write r ¨Ä ° d ONLN dÚZê )V equest befor ø ° d ONLN d˛êˆ )6e you call this function ° d ONLN d l è ( l at interr Ÿ` ° d ONLN d è ∑ )# upt time.
° d ONLN d*6 *> D (< *RESUL èU ° d ONLN d/6 D> h )T CODES
. ° d ONLN d7D lP ä +(noErr . ° d ONLN d=E ¯P ˝ )å0 ° d ONLN d?EP- )No err E† ° d ONLN dEE.P7 ) or . ° d ONLN dHO l[ ñ (X lwritErr . ° d ONLN dPP Ó[ ˝ )Ç–20 ° d ONLN dTP[L )#Driver can’t r ã ° d ONLN dbPL[ó );espond to write r 1@ ° d ONLN dsPò[∏ )Lequests . ° d ONLN d{Z lf ® (c l
badUnitErr . ° d ONLN dÜ[ Óf ˝ )Ç–21 ° d ONLN dä[f( )#Refer ⁄ ° d ONLN dè[(f” )&ence number out of range or not in use . ° d ONLN d∂e lq ¥ (n l unitEmptyErr . ° d ONLN d√f Óq ˝ )Ç–22 ° d ONLN d«fqÅ )#DCE points to null driver . ° d ONLN d·p l| ® (y l
notOpenErr . ° d ONLN dÏq Ó| ˝ )Ç–26 ° d ONLN dq|\ )#Driver isn’t open . ° d ONLN d{ lá ú (Ñ labortErr . ° d ONLN d | Óá ˝ )Ç–27 ° d ONLN d|á )#W ¬† ° d ONLN d|áx ) rite aborted by KillIO
° d ONLN d0∞ lª +B%For information about the low-level r Ɔ ° d ONLN dU∞ªÊ )§3outine for writing to device drivers, see the next . ° d ONLN dຠl« Ò (ƒ l section, which describes the ° d ONLN d•ª Ò« )ÖPBWrite ° d ONLN d¨º«E )*
function.
*¯ 4
*¯
*
˛
ˇ·ˇ‚7^
. ° d ONLN d∏¸ * E ( *PBW Ú@ ° d ONLN dª¸ D V )rite ˇˇˇˇˇˇ (Ú1
. ° d ONLN d¿ l' s ($ lY ï ° d ONLN d¡ r' µ )ou can use the ï ° d ONLN d– µ' fl )CPBWrite ï ° d ONLN d◊ fl'R )* function to write data fr g` ° d ONLN dÒ R'í )s
om a data buf 9¿ ° d ONLN d˛ í'Ò )@fer to an open driver |` ° d ONLN d 'Û )^. ° d ONLN d3 l? ¢ (< l FUNCTION ° d ONLN d 3 ¢? Ã )6PBWrite ° d ONLN d-3 Ã? “ )* ° d ONLN d.3 “?b )(paramBlock: ParmBlkPtr; ° d ONLN dOA ΔM Ã (J Δ ° d ONLN dPA ÃM “ ) ° d ONLN dQA “Mb ) async: Boolean): OSErr; ° d ONLN djY le ® (b l
paramBlock . ° d ONLN duZ Æeh )B*Contains a pointer to the parameter block. . ° d ONLN d†i lu ä (r lasync . ° d ONLN d¶j Æu À )BSpecifi ‡ ° d ONLN d≠j Àux ) &es to the Device Manager whether the r RÄ ° d ONLN d”jyuƒ )Æequest is asynchr Œ‡ ° d ONLN d‰jƒu‰ )Konous. ˇ ‹ @ ˇ ˇˇˇˇ @
ˇ·ˇ‚7^
4 H \ , Palatino
. +ä"CHAPTER œ´ )\1 , Helvetica
( @ äThe Device Manager 4⁄ ä˙ (‡ ä Reference to the Device Manager
° d ONLN d ] ä h ê ( e äY @Ä ° d ONLN d ] ê h ˆ )ou specify values and r P ° d ONLN d ] ˆ h )feceive r ¿ ° d ONLN d ] h¯ )!1eturn values in a Device Manager parameter block.
u H Ö 4 v H Ñ
° d ONLN dˇˇ ( } äParameter block
ˇ·ˇ‚7^ , Symbol
° d ONLN dˇˇ *Æ ,
Courier . ° d ONLN dˇˇ ) ioCompletion ° d ONLN dˇˇ )QProcPtr . ° d ONLN dˇˇ )8Pointer to completion r ì‡ ° d ONLN dˇˇ )foutine. ° d ONLN dˇˇ ( ó ä¨ . ° d ONLN dˇˇ ) ioResult ° d ONLN dˇˇ )QOSErr . ° d ONLN dˇˇ )8 Result code. ° d ONLN dˇˇ ( £ äÆ . ° d ONLN dˇˇ ) ioVRefNum ° d ONLN dˇˇ )QInteger . ° d ONLN dˇˇ )8 Drive number ; ° d ONLN dˇˇ )>. ° d ONLN dˇˇ ( Ø äÆ . ° d ONLN dˇˇ ) ioRefNum ° d ONLN dˇˇ )QInteger . ° d ONLN dˇˇ )8Driver r ø¿ ° d ONLN dˇˇ )#efer k‡ ° d ONLN dˇˇ ) ence number Û¿ ° d ONLN dˇˇ )8. ° d ONLN dˇˇ ( ª äÆ . ° d ONLN dˇˇ ) ioBuffer ° d ONLN dˇˇ )QPtr . ° d ONLN dˇˇ )8Pointer to data buf Ä ° d ONLN dˇˇ )Sfer U@ ° d ONLN dˇˇ ) . ° d ONLN dˇˇ ( « äÆ . ° d ONLN dˇˇ )
ioReqCount ° d ONLN dˇˇ )QLongInt . ° d ONLN dˇˇ )8#Requested number of bytes to write. ° d ONLN dˇˇ ( ” ä¨ . ° d ONLN dˇˇ )
ioActCount ° d ONLN dˇˇ )QLongInt . ° d ONLN dˇˇ )8 Actual number of bytes written. ° d ONLN dˇˇ ( fl äÆ . ° d ONLN dˇˇ ) ioPosMode ° d ONLN dˇˇ )QInteger . ° d ONLN dˇˇ )8Positioning mode. . ° d ONLN dˇˇ ( Î ä´ ° d ONLN dˇˇ ) ioPosOffset ° d ONLN dˇˇ )QLongInt . ° d ONLN dˇˇ )8Positioning of ˙¿ ° d ONLN dˇˇ )=fset.
° d ONLN dN
H Å ( H DESCRIPTION
. ° d ONLN dZ ä# ü +BThe ° d ONLN d^ ü# … )PBWrite ° d ONLN de …#Ù )*A function attempts to write the number of bytes indicated by the ˇ˛:Ù ° d ONLN d¶# ä/ Δ (, ä
ioReqCount ˇˇ z ° d ONLN d∞$ Δ/ à )< f m˙ ° d ONLN d≤$ Ã/ È )ield fr ]‘ ° d ONLN dπ$ È/0 ) om the data buf ࢠ° d ONLN d»$0/é )Gfer pointed to by the ˇ˛:Ù ° d ONLN dfi#è/ø )_ioBuffer ˇˇ z ° d ONLN dÊ$ø/≈ )0 f ˛ ° d ONLN dË$≈/ )ield to the driver ˇˇ.¢ ° d ONLN d˚0 ä; ® (8 äspecifi ° d ONLN d0 ®; ‘ )
ed by the ˇ˛]D Ê ° d ONLN d / ’; )-ioRefNum ˇˇ.¢ Ê ° d ONLN d0; )0 fi :à ° d ONLN d0;" ) eld.
° d ONLN d 0";¿ )$After the transfer is complete, the ˇ˛]D "ñ ° d ONLN d@/¿;¸ )û
ioActCount ˇˇ.¢ "ñ ° d ONLN dJ0¸; )< fi Q8 ° d ONLN dM0; ) eld . ° d ONLN dQ< äGW (D ä/indicates the number of bytes actually written. . ° d ONLN dÅN äYQ *,For block devices such as disk drivers, the ° d ONLN d≠MQY{ )«PBWrite ° d ONLN d¥N{Y )*" function allows you to specify a ˇˇú£ ° d ONLN d÷Z äe Ê (b ädrive number in the ˇˇ9F Úå ° d ONLN dÍY Êe )\ ioVRefNum ˇˇú£ Úå ° d ONLN dÛZ e% )6 fi è/ ° d ONLN dˆZ&e‰ )
)eld and specify a positioning mode and of ™ ° d ONLN d Z‰e )æ fset in the ˇ˛”à ° d ONLN d+e äq ¿ (n ä ioPosMode ˇˇiƒ ° d ONLN d4f ¿q ’ )6 and ˇ˛”à Sà ° d ONLN d9e ÷q ) ioPosOffset ˇˇiƒ Sà ° d ONLN dDfq )B f çà ° d ONLN dFf q: )ields. ˜ê ° d ONLN dMf:qè ) Bits 0 and 1 of the ˇ˛”à r( ° d ONLN daeêq“ )V ioPosOffset ˇˇiƒ r( ° d ONLN dlf“qÿ )B f ¨l ° d ONLN dnfÿq )ield indicate . ° d ONLN d|r ä} † (z äwher 7 ° d ONLN dÄr °}" ) e an operation should begin r ¿ ° d ONLN dùr"}Í )Å/elative to the physical beginning of the block- ° d ONLN dÃ~ äâ ‚ (Ü äformatted medium. I` ° d ONLN dfi~ „â È )YY ‡ ° d ONLN dfl~ Èâ )Eou can use the following constants to test or set the value of these ° d ONLN d$ä äï ú (í äbits: . ° d ONLN d,° ä≠ ‰ *CONST fsAtMark ° d ONLN d;° ‰≠ )Z ° d ONLN d=° ≠ ) = 0; ° d ONLN dB°≠å ) {at current position} ° d ONLN dYØ äª ê (∏ ä ° d ONLN dZØ êª ñ ) ° d ONLN d[Ø ñª ú ) ° d ONLN d\Ø úª ¢ ) ° d ONLN d]Ø ¢ª ® ) ° d ONLN d^Ø ®ª Æ ) ° d ONLN d_Ø Æª ¸ )
fsFromStart= ° d ONLN dlØ ¸ª )N1; ° d ONLN doتò ) {offset from beginning} ° d ONLN dàΩ ä… ê (Δ ä ° d ONLN dâΩ ê… ñ ) ° d ONLN däΩ ñ… ú ) ° d ONLN dãΩ ú… ¢ ) ° d ONLN dåΩ ¢… ® ) ° d ONLN dçΩ ®… Æ ) ° d ONLN déΩ Æ… ) fsFromMark ° d ONLN dôΩ … )B= 2; ° d ONLN dûΩ…¬ ) {offset from current position} . ° d ONLN dæ÷ ä· (fi ä$After the transfer is complete, the «@ ° d ONLN d‚÷ ·R )ñ ioPosOffset ≠‡ ° d ONLN dÌ÷S·[ )3 fi :† ° d ONLN d÷\·Œ ) eld indicates the new curr }‡ ° d ONLN d
÷Œ· )rent position of ° d ONLN d‚ äÌ À (Í äa block device.
° d ONLN d* H j ( HSPECIAL U ° d ONLN d1 k ü )#
CONSIDERA Á ° d ONLN d; û ∏ )3TIONS
ˇˇ…† . ° d ONLN dA ä" û ( äThe ˇˇì@ I† ° d ONLN dE ü" … )PBWrite ˇˇ…† I† ° d ONLN dL …"X )* function does not move memory ° d ONLN djX"á )è . However *@ ° d ONLN dsá"€ )/, you should be sur # ° d ONLN dÜ€" )T
e the device . ° d ONLN dì# ä." (+ ä driver does not move memory in r õ` ° d ONLN d≥#".x )òesponse to a write r ¨Ä ° d ONLN d«#x.Æ )V equest befor ø ° d ONLN d”#Æ. )6e you call this function ° d ONLN dÏ/ ä: ≠ (7 ä at interr Ÿ` ° d ONLN dı/ ≠: ’ )# upt time.
° d ONLN dˇV H^ n (\ HASSEMBL ‹è ° d ONLN dV n^ r )&Y ö∫ ° d ONLN dV s^ – )-LANGUAGE INFORMA —U ° d ONLN dV –^ Â )]TION
ˇˇ\ . ° d ONLN d d äo (l ä
The trap macr ] ° d ONLN d*d o Ú )@
o for the ˇ˛
∏ m, ° d ONLN d4c Úo )(PBWrite ˇˇ\ m, ° d ONLN d;d oN )*
function is ˇ˛
∏ }@ ° d ONLN dHcNor )2_Write ˇˇ\ }@ ° d ONLN dNdro )$$ ($A003). Set bit 10 of the trap wor zÄ ° d ONLN drdo )úd . ° d ONLN dtp ä{ œ (x äto execute this r ı@ ° d ONLN dÖp œ{ )Eoutine asynchr [¿ ° d ONLN dìp{4 )Bonously ∏ ° d ONLN döp3{Õ )"%. Set bit 9 to execute it immediately ù‡ ° d ONLN døpÃ{Œ )ô. . ° d ONLN d¡Ç äç ë (ä äY ï ° d ONLN d¬Ç êç ‘ )ou must setup r g` ° d ONLN d—Ç ‘ç ˆ )Degister ° d ONLN dŸÇ ˆçI )"A0 with the addr €` ° d ONLN dÈÇHçÁ )R!ess of the parameter block. When €` ° d ONLN d
ÅÁç )ü_Write €` ° d ONLN dÇ ç )$ . ° d ONLN dé äô ç (ñ är E ° d ONLN dé éô ≥ ) eturns, r ° d ONLN dé ≥ô )%egister D0 contains the r Í¿ ° d ONLN d4é ô∏ )j%esult code. Register D0 is the only r \Ä ° d ONLN dYéπô· )ú
egister af Ä ° d ONLN dcé·ô )(
fected by ° d ONLN dmö ä• † (¢ äthis r ˛ ° d ONLN dsö †• æ )outine. ˇZ @ ˇ ˇˇˇˇ @
° d ONLN d k l v x *A0 ° d ONLN d k ® v Ω )<addr |Ä ° d ONLN d k Ω v0 )ess of the parameter block
° d ONLN d 5 z l Ö ¥ ( Ç lRegisters on exit
° d ONLN d G â l î x *D0 ° d ONLN d J â ® î ´ )<r E ° d ONLN d K â ¨ î ÿ )
esult code
° d ONLN d V Ø * ∑ D ( µ *RESUL èU ° d ONLN d [ Ø D ∑ h )T CODES ,
Courier
. ° d ONLN d c Ω l … ä +(noErr . ° d ONLN d i æ ¯ … ˝ )å0 ° d ONLN d k æ …- )No err E† ° d ONLN d q æ. …7 ) or . ° d ONLN d t » l ‘ ñ ( — lwritErr . ° d ONLN d | … Ó ‘ ˝ )Ç–20 ° d ONLN d Ä … ‘L )#Driver can’t r ã ° d ONLN d é …L ‘~ ); espond to r s@ ° d ONLN d ô …~ ‘î )2ead r ù† ° d ONLN d û …î ‘¥ )equests . ° d ONLN d ¶ ” l fl ® ( ‹ l
badUnitErr . ° d ONLN d ± ‘ Ó fl ˝ )Ç–21 ° d ONLN d µ ‘ fl( )#Refer ⁄ ° d ONLN d ∫ ‘( fl” )&ence number out of range or not in use . ° d ONLN d · fi l Í ¥ ( Á l unitEmptyErr . ° d ONLN d Ó fl Ó Í ˝ )Ç–22 ° d ONLN d Ú fl ÍÅ )#DCE points to null driver . ° d ONLN d È l ı ® ( Ú l
notOpenErr . ° d ONLN d Í Ó ı ˝ )Ç–26 ° d ONLN d Í ı\ )#Driver isn’t open . ° d ONLN d- Ù l ú ( ˝ labortErr . ° d ONLN d6 ı Ó ˝ )Ç–27 ° d ONLN d: ı )#W ¬† ° d ONLN d; ı x ) rite aborted by KillIO
° d ONLN dR *" Q ( *SEE ALSO
° d ONLN d[) l4 +B&For information about the high-level r ° d ONLN dÅ)4‘ )®.outine for writing to device drivers, see the . ° d ONLN dØ5 l@ v (= lpr R` ° d ONLN d±5 v@ )
$evious section, which describes the R` ° d ONLN d’4@E )•FSWrite R` ° d ONLN d‹5E@o )*
function.
p *x¯ 4q *x¯ q *q˛
ˇ·ˇ‚7^
. ° d ONLN dÁc *p H (m *Contr ˘Ä ° d ONLN dÏc Hp Í ) olling and Monitoring Devices ˇˇˇˇˇˇ (mÚ1
ˇˇh . ° d ONLN d
y lÑ s (Å lY ï ° d ONLN d y rÑ “ )ou can use either the ˇ˛– ù( ° d ONLN d!x “Ñ ¸ )`Control ˇˇh ù( ° d ONLN d(y ¸Ñ )* or ˇ˛– m8 ° d ONLN d,x
Ñ@ ) PBControl ˇˇh m8 ° d ONLN d5y@ц )6 function to send contr fl∏ ° d ONLN dLy†Ñ˜ )`ol information to a ° d ONLN d`Ö lê ™ (ç l
equest queue. ° d ONLN dHØ l∫ Å (∑ lThe ° d ONLN dLÆ Å∫ ∑ ) PBControl ° d ONLN dUØ ∑∫ Ω )6, ° d ONLN dWÆ Ω∫ Ì )PBStatus ° d ONLN d_Ø Ì∫ )0, and ° d ONLN deÆ∫= ) PBKillIO ° d ONLN dnØ=∫◊ )6"functions use the additional contr R` ° d ONLN dêØ◊∫˜ )öol and . ° d ONLN dóª lΔ é (√ lstatus fi † ° d ONLN d†ª èΔS )#-elds of the parameter block, as described on Ä ° d ONLN dÕªSΔs )ƒpage 1- G@ ° d ONLN d‘ªsΔ} ) 16 G@ ° d ONLN d÷ª}Δ )
csParamPtr . ° d ONLN d*g ÆrQ )B&Contains a pointer to the actual contr <‡ ° d ONLN dPgRrî )§ol information.
° d ONLN d`ç *ï c (ì * DESCRIPTION
ˇˇB . ° d ONLN dlú lß Ä +BThe ˇ˛Ñ, ¬ ° d ONLN dpõ Äß ™ )Control ˇˇB ¬ ° d ONLN dwú ™ß† )*7 function sends information to the device driver specifi “Δ ° d ONLN dØú†ß– )ˆ ed by the r kh ° d ONLN d∫ú—ß„ )1efer =» ° d ONLN dæú„߯ )ence ˇˇ † ° d ONLN d√® l≥ ´ (∞ lnumber in the ˇ˛@ •‡ ° d ONLN d—ß ´≥ œ )?refNum ˇˇ † •‡ ° d ONLN d◊® œ≥ )$
parameter ı ° d ONLN d·® ≥z )1 . The value you pass in the ˇ˛@ MÄ ° d ONLN d˝ß{≥ü ){csCode ˇˇ † MÄ ° d ONLN d®ü≥¯ )$ parameter and the ˇà @ ˇ ˇˇˇˇ @
ˇ·ˇ‚7^
4 H \ , Palatino
. +ä"CHAPTER œ´ )\1 , Helvetica
( @ äThe Device Manager 4⁄ ä˙ (‡ ä Reference to the Device Manager
. ° d ONLN d ] ä h: ( e ä&type of information pointed to by the ,
Courier ° d ONLN d & \: hv )∞
csParamPtr ° d ONLN d 0 ]v h )< parameter depend on the driver . ° d ONLN d P i ä t Á ( q äbeing called. For mor F@ ° d ONLN d e i Ë tf )^ e information, see the specifi g ° d ONLN d É if t’ )~c chapters for the standar !Ä ° d ONLN d ù i÷ t )p
d drivers. ˇ˛ˇ˛ . ° d ONLN d ® x ä É ù ( Ä äThe ˇ˝ˇ¸ ˛ ° d ONLN d ¨ w û É » )Control ˇ˛ˇ˛ ˛ ° d ONLN d ≥ x » É£ )*3 function is a high-level version of the low-level ˇ˝ˇ¸ Ï ° d ONLN d Ê w§ É⁄ )‹ PBControl ˇ˛ˇ˛ Ï ° d ONLN d Ô x⁄ É )6 function. Use ° d ONLN d ˛ Ñ ä è ù ( å äthe ° d ONLN d É ù è ” ) PBControl ° d ONLN d Ñ ” è )6I function, described in the next section, if you need to specify a drive . ° d ONLN dT ê ä õ ( ò ä number or if you want the contr ' ° d ONLN ds ê õ& )éol r ° d ONLN dw ê& õÄ )equest to be asynchr ™ ° d ONLN dã êÄ õù )Zonous.
° d ONLN dí ∂ H æ j ( º HSPECIAL U ° d ONLN dô ∂ k æ ü )#
e the device . ° d ONLN d˚ — ä ‹" ( Ÿ ä driver does not move memory in r õ` ° d ONLN d —" ‹q )òesponse to a contr Ë ° d ONLN d- —q ‹ )Ool r ä‡ ° d ONLN d1 —Ä ‹∂ ) equest befor ù` ° d ONLN d= —∂ ‹ı )6e you call this ° d ONLN dM › ä Ë ‘ (  äfunction at interr g† ° d ONLN d_ › ’ Ë ˝ )K upt time.
° d ONLN di H b ( HRESUL èU ° d ONLN dn b Ü )T CODES
. ° d ONLN dv ä ® +(noErr . ° d ONLN d| )å0 ° d ONLN d~/ K )No err E† ° d ONLN dÑL U ) or . ° d ONLN dá ä( Δ (% ä
controlErr . ° d ONLN dí ( )Ç–17 ° d ONLN dñ /(j )#Driver can’t r ã ° d ONLN d§ j(¡ );espond to this contr %‡ ° d ONLN d∏ ¬(– )Xol r »¿ ° d ONLN dº –(Ï )equest . ° d ONLN d√' ä3 Δ (0 ä
badUnitErr . ° d ONLN dŒ( 3 )Ç–21 ° d ONLN d“(/3F )#Refer ⁄ ° d ONLN d◊(F3Ò )&ence number out of range or not in use . ° d ONLN d˛2 ä> “ (; ä unitEmptyErr . ° d ONLN d 3 > )Ç–22 ° d ONLN d3/>ü )#DCE points to null driver . ° d ONLN d)= äI Δ (F ä
notOpenErr . ° d ONLN d4> I )Ç–26 ° d ONLN d8>/Iz )#Driver isn’t open . ° d ONLN dJH äT ∫ (Q äabortErr . ° d ONLN dSI T )Ç–27 ° d ONLN dWI/TH )#Contr Â@ ° d ONLN d\IHTV )ol r à ° d ONLN d`IWT√ )equest aborted by KillIO
° d ONLN dyn Hv o (t HSEE ALSO
° d ONLN dÇ} äà. +B%For information about the low-level r Ɔ ° d ONLN dß}.àr )§outine for contr kÄ ° d ONLN d∑}sà )E$olling device drivers, see the next . ° d ONLN d€â äî (ë ä section, which describes the ° d ONLN d¯àîE )Ö PBControl ° d ONLN dâEîo )6
paramBlock . ° d ONLN dÕ Ã Ü )B*Contains a pointer to the parameter block. . ° d ONLN d¯$ ä0 ® (- äasync . ° d ONLN d˛% Ã0 È )BSpecifi ‡ ° d ONLN d% È0ñ ) &es to the Device Manager whether the r RÄ ° d ONLN d+%ó0‚ )Æequest is asynchr Œ‡ ° d ONLN d<%‚0 )Konous. ° d ONLN dD7 äB ê (? äY @Ä ° d ONLN dE7 êB ˆ )ou specify values and r P ° d ONLN d\7 ˆB )feceive r ¿ ° d ONLN dd7B¯ )!1eturn values in a Device Manager parameter block.
O H_ 4P H^
° d ONLN dˇˇ (W äParameter block
ˇ·ˇ‚7^ , Symbol
° d ONLN dˇˇ *Æ . ° d ONLN dˇˇ ) ioCompletion ° d ONLN dˇˇ )QProcPtr . ° d ONLN dˇˇ )8Pointer to completion r ì‡ ° d ONLN dˇˇ )foutine. ° d ONLN dˇˇ (q ä¨ . ° d ONLN dˇˇ ) ioResult ° d ONLN dˇˇ )QOSErr . ° d ONLN dˇˇ )8 Result code. ° d ONLN dˇˇ (} äÆ . ° d ONLN dˇˇ ) ioVRefNum ° d ONLN dˇˇ )QInteger . ° d ONLN dˇˇ )8 Drive number ; ° d ONLN dˇˇ )>. . ° d ONLN dˇˇ (â äÆ ° d ONLN dˇˇ ) ioCRefNum ° d ONLN dˇˇ )QInteger . ° d ONLN dˇˇ )8Driver r ø¿ ° d ONLN dˇˇ )#efer k‡ ° d ONLN dˇˇ ) ence number Û¿ ° d ONLN dˇˇ )8. ° d ONLN dˇˇ (ï äÆ . ° d ONLN dˇˇ ) csCode ° d ONLN dˇˇ )QPtr . ° d ONLN dˇˇ )8T ∫¿ ° d ONLN dˇˇ ) ype of contr ùÄ ° d ONLN dˇˇ )5ol call. ° d ONLN dˇˇ (° äÆ . ° d ONLN dˇˇ ) csParam ° d ONLN dˇˇ )QARRAY[1..10] OF Integer . ° d ONLN dˇˇ +8 Contr Â@ ° d ONLN dˇˇ )ol information. ˇ @ ˇ ˇˇˇˇ @
Courier ° d ONLN d k Å w ∑ ) PBControl ° d ONLN d l ∑ w≥ )67 function sends information to the device driver specifi ° d ONLN d Q l≥ w‚ )¸
ed by the ˇ˝Kfi ° d ONLN d [ w l É ¢ ( Ä l ioCRefNum ˇ˛•Ô ° d ONLN d d x ¢ É ß )6 f ˆo ° d ONLN d f x ß É1 ) ield. The value you pass in the ˇ˝Kfi ¯ ° d ONLN d Ü w2 ÉV )ãcsCode ˇ˛•Ô ¯ ° d ONLN d å xV É[ )$ f ˆg ° d ONLN d é x[ ɘ )$ield and the type of information in ˇˇŸ! ° d ONLN d ≤ Ñ l è ~ ( å lthe ˇˇ≤B Y! ° d ONLN d ∂ É è ª )
° d ONLN d8 ∂ * æ L ( º *SPECIAL U ° d ONLN d? ∂ M æ Å )#
CONSIDERA Á ° d ONLN dI ∂ Ä æ ö )3TIONS
. ° d ONLN dO ≈ l – Å ( Õ lThe ° d ONLN dS ƒ Å – ∑ ) PBControl ° d ONLN d\ ≈ ∑ –H )6 function does not move memory d@ ° d ONLN dz ≈G –w )ê . However ¶‡ ° d ONLN dÉ ≈v –À )/, you should be sur y@ ° d ONLN dñ ≈À –Ê )Ue the . ° d ONLN dú — l ‹# ( Ÿ l'device driver does not move memory in r …@ ° d ONLN d√ —# ‹r )∑esponse to a contr ‡ ° d ONLN d’ —s ‹Å )Pol r ∏¿ ° d ONLN dŸ —Å ‹∑ ) equest befor À@ ° d ONLN d —∑ ‹ˆ )6e you call this ° d ONLN dı › l Ë ∂ (  lfunction at interr g† ° d ONLN d › ∑ Ë fl )K upt time.
° d ONLN d * P ( *ASSEMBL ‹è ° d ONLN d P T )&Y ö∫ ° d ONLN d U ≤ )-LANGUAGE INFORMA —U ° d ONLN d* ≤ « )]TION
ˇˇŸ . ° d ONLN d/ l ¨ ( l
The trap macr x ° d ONLN d< ¨ ‘ )@
o for the ˇ˛%≤ ∞ù ° d ONLN dF ‘
)( PBControl ˇˇŸ ∞ù ° d ONLN dO
< )6
function is ˇ˛%≤ È( ° d ONLN d\< l )2_Control ˇˇŸ È( ° d ONLN ddl ˜ )0! ($A004). Set bit 10 of the trap . ° d ONLN dÖ l) } (& lwor Ä ° d ONLN dà ~) à )d to execute this r "Ä ° d ONLN dõ Ã)
)0 )Aonously Â@ ° d ONLN d∞ /)… )"%. Set bit 9 to execute it immediately À ° d ONLN d’ ») )ô. ˇˇ∞S . ° d ONLN d◊0 l; s (8 lY ï ° d ONLN dÿ0 r; µ )ou must setup r xY ° d ONLN dÁ0 µ; ÷ )Cegister L ° d ONLN dÔ0 ÷;( )!A0 with the addr ≠• ° d ONLN dˇ0(;≈ )R!ess of the parameter block. When ˇˇ`¶ œó ° d ONLN d /≈;ı )ù_Control ˇˇ∞S œó ° d ONLN d(0ı;˜ )0 . ° d ONLN d)< lG o (D lr E ° d ONLN d*< pG ï ) eturns, r ° d ONLN d3< ïG ˇ )%egister D0 contains the r Í¿ ° d ONLN dL< ˇGö )j%esult code. Register D0 is the only r \Ä ° d ONLN dq<õG√ )ú
egister af Ä ° d ONLN d{<√GÌ )(
fected by ° d ONLN dÖH lS Ç (P lthis r ˛ ° d ONLN dãH ÇS † )outine.
° d ONLN d⁄Ñ lè x *D0 ° d ONLN d›Ñ ®è ´ )<r E ° d ONLN dfiÑ ¨è ÿ )
esult code
° d ONLN dÈ™ *≤ D (∞ *RESUL èU ° d ONLN dÓ™ D≤ h )T CODES
. ° d ONLN dˆ∏ lƒ ä +(noErr . ° d ONLN d¸π ¯ƒ ˝ )å0 ° d ONLN d˛πƒ- )No err E† ° d ONLN dπ.ƒ7 ) or . ° d ONLN d√ lœ ® (à l
controlErr . ° d ONLN dƒ Óœ ˝ )Ç–17 ° d ONLN dƒœL )#Driver can’t r ã ° d ONLN d$ƒLœ£ );espond to this contr %‡ ° d ONLN d8ƒ§œ≤ )Xol r »¿ ° d ONLN d<ƒ≤œŒ )equest . ° d ONLN dCŒ l⁄ ® (◊ l
notOpenErr ° d ONLN d¥Â Ó ˝ )Ç–26 . ° d ONLN d∏Â\ )#Driver isn’t open . ° d ONLN d Ô l˚ ú (¯ labortErr . ° d ONLN d” Ó˚ ˝ )Ç–27 ° d ONLN d◊˚* )#Contr Â@ ° d ONLN d‹*˚8 )ol r à ° d ONLN d‡9˚• )equest aborted by KillIO
° d ONLN d˘ * Q ( *SEE ALSO
° d ONLN d$ l/ +B&For information about the high-level r ° d ONLN d($/X )®outine for contr –‡ ° d ONLN d8$X/ÿ )D olling device drivers, see the . ° d ONLN dW0 l; v (8 lpr R` ° d ONLN dY0 v; )
$evious section, which describes the R` ° d ONLN d}/;E )•Control R` ° d ONLN dÑ0E;o )*
function.
k *s¯ 4l *s¯ l *l˛
ˇ·ˇ‚7^
. ° d ONLN dê^ *k K (h *Status ˇˇˇˇˇˇ (hÚ1
. ° d ONLN dó~ lâ s (Ü lY ï ° d ONLN dò~ râ µ )ou can use the ï ° d ONLN dß} µâ Ÿ )CStatus ï ° d ONLN d≠~ Ÿâé )$) function to obtain status information fr g` ° d ONLN d÷~éâ )µom a device driver ™ ° d ONLN dË~‰âÁ )V. ° d ONLN dÍï l° Δ (û lFUNCTION Status ° d ONLN dï ÿ°§ )l"(refNum: Integer; csCode: Integer; ° d ONLN d.£ ÿØ fi * ° d ONLN d/£ fiØn )csParamPtr: Ptr): OSErr; ˇ @ ˇ ˇˇˇˇ @
ˇ·ˇ‚7^
4 H \ , Palatino
. +ä"CHAPTER œ´ )\1 , Helvetica
( @ äThe Device Manager 4⁄ ä˙ (‡ ä Reference to the Device Manager
. ° d ONLN d \ ä h Æ ( e ärefNum . ° d ONLN d ] Ã h
)BContains the r π` ° d ONLN d ]
h )>efer eÄ ° d ONLN d ] hµ )"ence number identifying the driver ô¿ ° d ONLN d ; ]µ h∑ )ö. . ° d ONLN d = l ä x Æ ( u äcsCode . ° d ONLN d D m à x )BContains a driver B† ° d ONLN d U m x˛ )M3-dependent code specifying the type of information ° d ONLN d à y Ã Ñ œ ( Å Ãr E ° d ONLN d â y – Ñ ˙ ) equested. . ° d ONLN d ì à ä î Δ ( ë ä
csParamPtr . ° d ONLN d ü â Ã îì )B.Contains a pointer to the status information r ‚Ä ° d ONLN d Õ âì î∂ )«eceived.
° d ONLN d ÷ Ø H ∑ Å ( µ H DESCRIPTION
ˇˇ†Ω . ° d ONLN d ‚ æ ä … û +BThe ˇˇAz Ω ° d ONLN d Ê Ω ü … √ )Status ˇˇ†Ω Ω ° d ONLN d Ï æ √ … )$ function r 4ó ° d ONLN d ˜ æ …Ô )-7eturns information about the device driver having the r fl ° d ONLN d. æÔ … )ˇefer fl? ° d ONLN d2 æ … )ence ° d ONLN d7 ä ’ À ( “ ä
number specifi ° d ONLN dE À ’ ˙ )A
ed by the ° d ONLN dO … ˙ ’ )/refNum ° d ONLN dU ’Q )$
parameter ¬† ° d ONLN d_ P ’— )2 . The value you pass in the ¬† ° d ONLN d{ …— ’ı )ÅcsCode ¬† ° d ONLN dÅ ı ’¯ )$ ° d ONLN dÇ ÷ ä · ∫ ( fi ä parameter ¬† ° d ONLN dã ÷ π · Í )/ , and the r ï ° d ONLN dñ ÷ Í ·ú )1&eceived information pointed to by the ï ° d ONLN dº ’ú ·ÿ )≤
csParamPtr ï ° d ONLN dΔ ÷ÿ · )< parameter . ° d ONLN d— ‚ ä ÌH ( Í ä*depend on the driver being called. For mor b ° d ONLN d˚ ‚H ÌΔ )æ e information, see the specifi Ç¿ ° d ONLN d ‚Δ Ì )~c chapters for the ° d ONLN d, Ó ä ˘ ´ ( ˆ ästandar ±Ä ° d ONLN d3 Ó ´ ˘ ’ )!
d drivers. ˇˇƒÍ . ° d ONLN d> ˝ ä û ( äThe ˇˇâ‘ DÍ ° d ONLN dB ¸ ü √ )Status ˇˇƒÍ DÍ ° d ONLN dH ˝ √• )$3 function is a high-level version of the low-level ˇˇâ‘ 1$ ° d ONLN d{ ¸¶÷ )„PBStatus ˇˇƒÍ 1$ ° d ONLN dÉ ˝÷ )0 function. Use ˇˇ√¡ ° d ONLN dí ä ú ( äthe ˇˇáÇ C¡ ° d ONLN dñ ù Õ )PBStatus ˇˇ√¡ C¡ ° d ONLN dû Õ )0J function if you need to specify a drive number or if you want the status . ° d ONLN dË ä ç ( är E ° d ONLN dÈ é Ë )equest to be asynchr % ° d ONLN d˝ Ë )Zonous.
° d ONLN d; HC j (A HSPECIAL U ° d ONLN d ; kC ü )#
CONSIDERA Á ° d ONLN d; ûC ∏ )3TIONS
. ° d ONLN dJ äU ü (R äThe ° d ONLN d I üU √ )Status ° d ONLN d%J √UT )$ function does not move memory d@ ° d ONLN dCJSUÉ )ê . However ¶‡ ° d ONLN dLJÇU◊ )/, you should be sur y@ ° d ONLN d_J◊U )U
e the device . ° d ONLN dlV äa" (^ ä driver does not move memory in r õ` ° d ONLN dåV"a{ )òesponse to a status r t` ° d ONLN d°V{a± )Y equest befor ܇ ° d ONLN d≠V±a )6e you call this ° d ONLN dΩb äm ‘ (j äfunction at interr g† ° d ONLN dœb ’m ˝ )K upt time.
° d ONLN dŸà Hê b (é HRESUL èU ° d ONLN dfià bê Ü )T CODES
. ° d ONLN dÊñ ä¢ ® +(noErr . ° d ONLN dÏó¢ )å0 ° d ONLN dÓó/¢K )No err E† ° d ONLN dÙóL¢U ) or . ° d ONLN d˜° ä≠ ¿ (™ ä statusErr . ° d ONLN d¢ ≠ )Ç–18 ° d ONLN d¢/≠j )#Driver can’t r ã ° d ONLN d¢j≠À );espond to this status r ≤@ ° d ONLN d*¢À≠Á )aequest . ° d ONLN d1¨ ä∏ Δ (µ ä
badUnitErr . ° d ONLN d<≠ ∏ )Ç–21 ° d ONLN d@≠/∏F )#Refer ⁄ ° d ONLN dE≠F∏Ò )&ence number out of range or not in use . ° d ONLN dl∑ ä√ “ (¿ ä unitEmptyErr . ° d ONLN dy∏ √ )Ç–22 ° d ONLN d}∏/√ü )#DCE points to null driver . ° d ONLN dó¬ äŒ Δ (À ä
notOpenErr ° d ONLN d¢√ Œ )Ç–26 . ° d ONLN d¶√/Œz )#Driver isn’t open . ° d ONLN d∏Õ äŸ ∫ (÷ äabortErr . ° d ONLN d¡Œ Ÿ )Ç–27 ° d ONLN d≈Œ/ŸP )#Status r Õ† ° d ONLN dÕŒPŸº )!equest aborted by KillIO
° d ONLN dÊÛ H˚ o (˘ HSEE ALSO
° d ONLN dÔ ä
. +B%For information about the low-level r Ɔ ° d ONLN d.
)§3outine for monitoring device drivers, see the next ° d ONLN dG äX ( ä/section, which describes the PBStatus function.
X H` 4Y H` Y HY
ˇ·ˇ‚7^
° d ONLN dxK HX y (U HPBStatus ˇˇˇˇˇˇ (U1
. ° d ONLN dÅk äv ë (s äY ï ° d ONLN dÇk êv ” )ou can use the ï ° d ONLN dëj ”v )CPBStatus ï ° d ONLN dôkv∏ )0) function to obtain status information fr g` ° d ONLN d¬k∏v )µom a device driver ™ ° d ONLN d‘kv )V. ° d ONLN d÷Ç äéÜ (ã ä*FUNCTION PBStatus (paramBlock: ParmBlkPtr; ° d ONLN d
ê ˆúÄ +l async: Boolan): OSErr; ° d ONLN d"® ä¥ Δ (± ä
. ° d ONLN d \ l h ä ( e lasync . ° d ONLN d ] Æ h À )BSpecifi ‡ ° d ONLN d
] À hx ) &es to the Device Manager whether the r RÄ ° d ONLN d 3 ]y hƒ )Æequest is asynchr Œ‡ ° d ONLN d D ]ƒ h‰ )Konous. ° d ONLN d L o l z r ( w lY @Ä ° d ONLN d M o r z ÿ )ou specify values and r P ° d ONLN d d o ÿ z ˘ )feceive r ¿ ° d ONLN d l o ˘ z⁄ )!1eturn values in a Device Manager parameter block.
. ° d ONLN d˘ l Å +BThe ° d ONLN d˝ Å ± )PBStatus ° d ONLN d ± fl )0 function r R` ° d ONLN d fl › ).6eturns information about the device driver having the ˇˇÜÉ ° d ONLN dF l) p (& lr R` ° d ONLN dG p) Ç )efer $¿ ° d ONLN dK Ç) ÿ )ence number specifi 1Δ ° d ONLN d^ ÿ) )V
ed by the ˇˇ
≈O ° d ONLN dh ); )- ioCRefNum ˇˇÜÉ ≈O ° d ONLN dq ;)D )6 fi K“ ° d ONLN dt E)— )
eld. The value you pass in the ˇˇ
˘g ° d ONLN dì —)ı )åcsCode ˇˇÜÉ ˘g ° d ONLN dô ı)˜ )$ ° d ONLN dö* l5 s (2 lfi ° d ONLN dú* s5 È )eld and the information r R` ° d ONLN dµ* È5. )veceived in the R` ° d ONLN dƒ).5X )EcsParam R` ° d ONLN dÀ*X5b )* fi R` ° d ONLN dŒ*b5Û )
eld depend on the driver being . ° d ONLN dÌ6 lA Æ (> lcalled. For mor , ° d ONLN d¸6 ØA- )C e information, see the specifi L‡ ° d ONLN d6-Aú )~c chapters for the standar ` ° d ONLN d46ùA« )p
d drivers.
° d ONLN d?] *e L (c *SPECIAL U ° d ONLN dF] Me Å )#
CONSIDERA Á ° d ONLN dP] Äe ö )3TIONS
. ° d ONLN dVk lv Å (s lThe ° d ONLN dZj Åv ± )PBStatus ° d ONLN dbk ±vB )0 function does not move memory d@ ° d ONLN dÄkAvq )ê . However ¶‡ ° d ONLN dâkpv≈ )/, you should be sur y@ ° d ONLN dúk≈v‡ )Ue the . ° d ONLN d¢w lÇ# ( l'device driver does not move memory in r …@ ° d ONLN d…w#Ç| )∑esponse to a status r ¢@ ° d ONLN dfiw|Ç≤ )Y equest befor ¥¿ ° d ONLN dÍw≤ÇÒ )6e you call this ° d ONLN d˙É lé ∂ (ã lfunction at interr g† ° d ONLN d É ∑é fl )K upt time.
° d ONLN d™ *≤ P (∞ *ASSEMBL ‹è ° d ONLN d ™ P≤ T )&Y ö∫ ° d ONLN d ™ U≤ ≤ )-LANGUAGE INFORMA —U ° d ONLN d/™ ≤≤ « )]TION
ˇˇ“Ÿ . ° d ONLN d4∏ l√ ≠ (¿ l
The trap macr ¯ ° d ONLN dA∏ ≠√ ◊ )A
o for the ˇˇ•≤ pù ° d ONLN dK∑ ÿ√ )+PBStatus ˇˇ“Ÿ pù ° d ONLN dS∏√< )0
function is ˇˇ•≤ È( ° d ONLN d`∑<√f )4_Status ˇˇ“Ÿ È( ° d ONLN dg∏f√˜ )*! ($A005). Set bit 10 of the trap . ° d ONLN dàƒ lœ } (à lwor Ä ° d ONLN dム~œ à )d to execute this r "Ä ° d ONLN dûƒ Ãœ
)Noutine asynchr â ° d ONLN d¨ƒ
œ0 )Aonously Â@ ° d ONLN d≥ƒ/œ… )"%. Set bit 9 to execute it immediately À ° d ONLN dÿƒ»œ )ô. . ° d ONLN d⁄÷ l· s (fi lY ï ° d ONLN d€÷ r· ∂ )ou must setup r g` ° d ONLN dÍ÷ ∂· ÿ )Degister ° d ONLN dÚ÷ ÿ·+ )"A0 with the addr €` ° d ONLN d÷*·… )R!ess of the parameter block. When €` ° d ONLN d#’…·Û )ü_Status €` ° d ONLN d*÷Û·ˆ )* . ° d ONLN d+‚ lÌ o (Í lr E ° d ONLN d,‚ pÌ ï ) eturns, r ° d ONLN d5‚ ïÌ ˇ )%egister D0 contains the r Í¿ ° d ONLN dN‚ ˇÌö )j%esult code. Register D0 is the only r \Ä ° d ONLN ds‚õÌ√ )ú
egister af Ä ° d ONLN d}‚√ÌÌ )(
fected by ° d ONLN dáÓ l˘ Ç (ˆ lthis r ˛ ° d ONLN dçÓ Ç˘ † )outine.
° d ONLN dï˝ l ∫ ( lRegisters on entry
° d ONLN d® l x *A0 ° d ONLN d´ ® Ω )<addr |Ä ° d ONLN dØ Ω0 )ess of the parameter block
° d ONLN d l& ¥ (# lRegisters on exit
° d ONLN d‹* l5 x *D0 ° d ONLN dfl* ®5 ´ )<r E ° d ONLN d‡* ¨5 ÿ )
esult code
° d ONLN dÎQ *Y D (W *RESUL èU ° d ONLN dQ DY h )T CODES
. ° d ONLN d¯^ lj ä +(noErr . ° d ONLN d˛_ ¯j ˝ )å0 ° d ONLN d _j- )No err E† ° d ONLN d_.j7 ) or . ° d ONLN d i lu ¢ (r l statusErr ° d ONLN dj Óu ˝ )Ç–18 . ° d ONLN djuL )#Driver can’t r ã ° d ONLN d%jLu≠ );espond to this status r ≤@ ° d ONLN d<j≠u… )aequest . ° d ONLN dCt lÄ ® (} l
° d ONLN d l ä w1 +B&For information about the high-level r ° d ONLN d / l2 w¯ )®.outine for monitoring device drivers, see the . ° d ONLN d ] x ä É î ( Ä äpr R` ° d ONLN d _ x î É9 )
$evious section, which describes the ,
Courier R` ° d ONLN d É w9 É] )•Status R` ° d ONLN d â x] Éá )$
function.
≥ H ª 4 ¥ H ª ¥ H ¥
ˇ·ˇ‚7^
. ° d ONLN d ï ¶ H ≥ k ( ∞ HKillIO ˇˇˇˇˇˇ ( ∞1
ˇˇ1ä . ° d ONLN d ú Δ ä — ë ( Œ äY ï ° d ONLN d ù Δ ê — œ )ou can use the ˇ˛c [( ° d ONLN d ¨ ≈ – — Ù )@KillIO ˇˇ1ä [( ° d ONLN d ≤ Δ Ù —w )$ function to terminate all curr %: ° d ONLN d — Δx — )Ñ"ent and pending I/O with a device . ° d ONLN d Û “ ä › • ( ⁄ ädriver ‡ ° d ONLN d ˘ “ • › ß ). . ° d ONLN d ˚ È ä ıÄ ( Ú ä)FUNCTION KillIO (refNum: Integer): OSErr; ° d ONLN d% ä
Æ *refNum . ° d ONLN d, Ã
)BContains the r π` ° d ONLN d:
)>efer eÄ ° d ONLN d>
µ )"ence number identifying the driver ô¿ ° d ONLN d`µ
equests fr Oõ ° d ONLN dC”N¯ )*om the r `ù ° d ONLN d
C¯N )%equest . ° d ONLN dO äZ Ê (W äqueue for that driver ˆ ° d ONLN d)O ÂZ¶ )[+. The Device Manager calls the completion r Ö† ° d ONLN dTOßZ )¬outine for each pending ˇˇM . ° d ONLN dl[ äf ° (c äI/O r i≠ ° d ONLN dq[ °f Í )equest with the ˇ˛.ö Øî ° d ONLN dÅZ Íf )IioResult ˇˇM Øî ° d ONLN dâ[f# )0 fi Δ· ° d ONLN då[#f[ )
eld of each r fl( ° d ONLN dô[[fµ )8equest equal to the r º ° d ONLN dÆ[∂f‰ )[ esult code ˇ˛.ö =V ° d ONLN dπZ‰f ).abortErr ˇˇM ˆ ° d ONLN d¡[f )/. ˇˇ¢Ÿ ° d ONLN d√m äx (u äThe Device Manager passes ˇˇE≤ d ° d ONLN d›l x0 )ÇKillIO ˇˇ¢Ÿ d ° d ONLN d„m0x6 )$ r Äù ° d ONLN dÂm6x )3equests to a driver only if the driver is open and . ° d ONLN dy äÑ ’ (Å äenabled for contr ͇ ° d ONLN d)y ’Ñ ı )K ol calls.
ë Hû 4í Hù
° d ONLN dˇˇ (ô äIMPORT ° d ONLN dˇˇ ) ANT
ˇ·ˇ‚7^
° d ONLN d3ú äßé (§ ä;The KillIO function terminates all pending I/O for a driver I ° d ONLN dnúéßø (§é , including ° d ONLN dz® ä≥% (∞ ä$I/O initiated by other applications. ,
Zapf Dingbats
é` ° d ONLN dˇˇ )ûs ° d ONLN d≥œ H◊ j (’ HSPECIAL U ° d ONLN d∫œ k◊ ü )#
CONSIDERA Á ° d ONLN dƒœ û◊ ∏ )3TIONS
. ° d ONLN d › äË ü ( äThe ° d ONLN dŒ‹ üË √ )KillIO ° d ONLN d‘› √ËT )$ function does not move memory d@ ° d ONLN dÚ›SËÉ )ê . However ¶‡ ° d ONLN d˚›ÇË◊ )/, you should be sur y@ ° d ONLN d›◊Ë )U
e the device . ° d ONLN dÈ äÙ" (Ò ä driver does not move memory in r õ` ° d ONLN d;È"Ùi )òesponse to this r '† ° d ONLN dLÈjÙ† )H equest befor : ° d ONLN dXȆ٠)6 e you call this function at ° d ONLN dtı ä ¢ (˝ äinterr ° d ONLN dzı £ À ) upt time.
° d ONLN dÑ H$ b (" HRESUL èU ° d ONLN dâ b$ Ü )T CODES
. ° d ONLN dë) ä5 ® +(noErr . ° d ONLN dó*5 )å0 ° d ONLN dô*/5K )No err E† ° d ONLN dü*L5U ) or . ° d ONLN d¢4 ä@ ¿ (= ä statusErr . ° d ONLN d¨5 @ )Ç–18 ° d ONLN d∞5/@j )#Driver can’t r ã ° d ONLN dæ5j@À );espond to this status r ≤@ ° d ONLN d’5À@Á )aequest . ° d ONLN d‹? äK Δ (H ä
badUnitErr . ° d ONLN dÁ@ K )Ç–21 ° d ONLN dÎ@/KF )#Refer ⁄ ° d ONLN d@FKÒ )&ence number out of range or not in use . ° d ONLN dJ äV “ (S ä unitEmptyErr . ° d ONLN d$K V )Ç–22 ° d ONLN d(K/Vü )#DCE points to null driver . ° d ONLN dBU äa Δ (^ ä
notOpenErr . ° d ONLN dMV a )Ç–26 ° d ONLN dQV/az )#Driver isn’t open
° d ONLN dc| HÑ o (Ç HSEE ALSO
° d ONLN dlä äï. +B%For information about the low-level r Ɔ ° d ONLN dëä.ïæ )§ outine for terminating pending r ã` ° d ONLN d±äæï¯ )êequests for a . ° d ONLN døñ ä° ß (û ädriver ¬† ° d ONLN d≈ñ ¶°k ) ,, see the next section, which describes the ¬† ° d ONLN dÒïk°õ )≈PBKillIO ¬† ° d ONLN d˘ñõ°≈ )0
Courier ï ° d ONLN d { µ á Â )CPBKillIO ï ° d ONLN d ! | Â ám )0 function to terminate all curr g` ° d ONLN d @ |m á )àent and pending I/O with a . ° d ONLN d [ à l ì ¶ ( ê l
device driver I¿ ° d ONLN d h à ¶ ì ® ):. . ° d ONLN d j ü l ´ ¢ ( ® l FUNCTION ° d ONLN d s ü ¢ ´ à )6PBKillI ° d ONLN d z ü à ´h )*O (paramBlock: ParmBlkPtr; ° d ONLN d ù ≠ Δ π à ( ∂ Δ ° d ONLN d ü ≠ ÿ π fi ) ° d ONLN d † ≠ fi πn )async: Boolean) : OSErr; ° d ONLN d π ≈ l — ® ( Œ l
paramBlock . ° d ONLN d ƒ Δ Æ —h )B*Contains a pointer to the parameter block. . ° d ONLN d Ô ’ l · ä ( fi lasync . ° d ONLN d ı ÷ Æ · À )BSpecifi ‡ ° d ONLN d ¸ ÷ À ·x ) &es to the Device Manager whether the r RÄ ° d ONLN d" ÷y ·ƒ )Æequest is asynchr Œ‡ ° d ONLN d3 ÷ƒ ·‰ )Konous. °¿ ° d ONLN d: ÷‰ ·Í ) Y b@ ° d ONLN d; ÷Í ·˜ )ou . ° d ONLN d> ‚ Æ ÌZ ( Í Æ$should always set this parameter to ° d ONLN db ·Z Ìx )¨FALSE ° d ONLN dg ‚x Ì{ ) . . ° d ONLN di Ù l ˇ r ( ¸ lY @Ä ° d ONLN dj Ù r ˇ ÿ )ou specify values and r P ° d ONLN dÅ Ù ÿ ˇ ˘ )feceive r ¿ ° d ONLN dâ Ù ˘ ˇ⁄ )!1eturn values in a Device Manager parameter block.
* ¯ 4
*¯
° d ONLN dˇˇ ( lParameter block
ˇ·ˇ‚7^ , Symbol
° d ONLN dˇˇ *Æ . ° d ONLN dˇˇ ) ioCompletion ° d ONLN dˇˇ )QProcPtr . ° d ONLN dˇˇ )8Pointer to completion r ì‡ ° d ONLN dˇˇ )foutine ° d ONLN dˇˇ (. l¨ . ° d ONLN dˇˇ ) ioResult ° d ONLN dˇˇ )QOSErr . ° d ONLN dˇˇ )8 Result code ° d ONLN dˇˇ (: lÆ . ° d ONLN dˇˇ ) ioCRefNum ° d ONLN dˇˇ )QInteger . ° d ONLN dˇˇ )8Driver r ø¿ ° d ONLN dˇˇ )#efer k‡ ° d ONLN dˇˇ ) ence number
° d ONLN d`Y *a c (_ * DESCRIPTION
. ° d ONLN dlg lr Å +BThe ° d ONLN dpf År ± )PBKillIO ° d ONLN dxg ±r )0 function stops any curr R` ° d ONLN dêgr/ )ient r $¿ ° d ONLN dïg/rs )equest being pr ˜ ° d ONLN d§grr◊ )Cocessed by the driver ˇˇ¿‚ ° d ONLN d∫s l~ ª ({ lindicated by the ˇˇÅƒ ¬¶ ° d ONLN dÀr ª~ Ò )O ioCRefNum ˇˇ¿‚ ¬¶ ° d ONLN d‘s Ò~ ˙ )6 fi Éà ° d ONLN d◊s ˚~$ )
eld and r ◊¨ ° d ONLN d‡s$~É ))emoves all pending r Ï≤ ° d ONLN dÙsÉ~≠ )_
equests fr Ù ° d ONLN d˛sÆ~Ì )+
om the driver ø ° d ONLN d sÓ~˜ )@’s . ° d ONLN d lä o (á lr E ° d ONLN d päl )7equest queue. The Device Manager calls the completion r OÄ ° d ONLN dFläÿ )¸outine for each pending . ° d ONLN d^ã lñ p (ì lr R` ° d ONLN d_ã pñ º )equest with the R` ° d ONLN doä ºñ Ï )LioResult R` ° d ONLN dwã Ïñ ˆ )0 fi R` ° d ONLN dzã ˆñ1 )
outine synchr ˜ ° d ONLN dù≤¿Ω‚ )<onously €` ° d ONLN d§≤·Ω‰ )!. ˇ˛¢⁄ ° d ONLN d¶ƒ lœ (à l$Note that the Device Manager passes ˇ˝E¥ Q ° d ONLN d √œG )´PBKillIO ˇ˛¢⁄ Q ° d ONLN d“ƒGœL )0 r ΔV ° d ONLN d‘ƒLœ˜ )*equests to a driver only if the driver is . ° d ONLN d˛– l€ „ (ÿ lopen and enabled for contr ͆ ° d ONLN d– „€ )w ol calls.
È *ı¯ 4È *ı¯
° d ONLN dˇˇ ( lIMPORT ° d ONLN dˇˇ ) ANT
ˇ·ˇ‚7^
ˇˇ}Ê . ° d ONLN d"Ù lˇ Ä (¸ lThe ˇ˛˚à ˝Ê ° d ONLN d&Û Äˇ ∞ )PBKillIO ˇˇ}Ê ˝Ê ° d ONLN d.Ù ∞ˇG )0" function terminates all pending r Eƒ ° d ONLN dPÙHˇü )òequests for a driver ° d ONLN ddÙüˇ§ )W, . ° d ONLN df l ú ( l including r C ° d ONLN dq ù G )1(equests initiated by other applications. ,
Zapf Dingbats
˜¿ ° d ONLN dˇˇ )∞s ° d ONLN dØ& *. L (, *SPECIAL U ° d ONLN d∂& M. Å )#
CONSIDERA Á ° d ONLN d¿& Ä. ö )3TIONS
. ° d ONLN dΔ5 l@ Å (= lThe ° d ONLN d 4 Å@ ± )PBKillIO ° d ONLN d“5 ±@B )0 function does not move memory d@ ° d ONLN d5A@q )ê . However ¶‡ ° d ONLN d˘5p@≈ )/, you should be sur y@ ° d ONLN d 5≈@‡ )Ue the . ° d ONLN dA lL# (I l'device driver does not move memory in r …@ ° d ONLN d9A#Lj )∑esponse to this r UÄ ° d ONLN dJAkL° )H equest befor h ° d ONLN dVA°L‡ )6e you call this ° d ONLN dfM lX ∂ (U lfunction at interr g† ° d ONLN dxM ∑X fl )K upt time.
° d ONLN dÇs *{ P (y *ASSEMBL ‹è ° d ONLN dâs P{ T )&Y ö∫ ° d ONLN däs U{ ≤ )-LANGUAGE INFORMA —U ° d ONLN dõs ≤{ « )]TION
ˇˇQj . ° d ONLN d†Ç lç ¨ (ä l
The trap macr ı4 ° d ONLN d≠Ç ¨ç ‘ )@
o for the ˇ˛¢‘ Èr ° d ONLN d∑Å ’ç ))PBKillIO ˇˇQj Èr ° d ONLN døÇç7 )0
function is ˇ˛¢‘ ›∞ ° d ONLN dÃÅ8çb )3_KillIO ˇˇQj ›∞ ° d ONLN d”Çbçé )*
($A006). R‰ ° d ONLN d›Çèçñ )-Y g‰ ° d ONLN dfiÇïç÷ )ou must setup r .Ç ° d ONLN dÌÇ◊ç¯ )Begister ° d ONLN dıé lô ø (ñ lA0 with the addr R` ° d ONLN dé øô^ )S!ess of the parameter block. When R` ° d ONLN d&ç^ôà )ü_KillIO R` ° d ONLN d-éàôè )* r $¿ ° d ONLN d/éèô¥ ) eturns, r ˜ ° d ONLN d8é≥ô )$ egister D0 . ° d ONLN dCö l• ß (¢ lcontains the r † ° d ONLN dQö ®•C )<%esult code. Register D0 is the only r Ñ` ° d ONLN dvöC•k )õ
egister af ß` ° d ONLN dÄök•¨ )(fected by this r Ò¿ ° d ONLN dêö¨• )Aoutine. ˇ( @ ˇ ˇˇˇˇ @
ˇ·ˇ‚7^
4 H \ , Palatino
. +ä"CHAPTER œ´ )\1 , Helvetica
( @ äThe Device Manager 4⁄ ä˙ (‡ ä Summary of the Device Manager
° d ONLN d k ä v ñ *A0 ° d ONLN d k Δ v € )<addr |Ä ° d ONLN d k € vN )ess of the parameter block
° d ONLN d 5 z ä Ö “ ( Ç äRegisters on exit
° d ONLN d G â ä î ñ *D0 ° d ONLN d J â Δ î … )<r E ° d ONLN d K â î ˆ )
esult code
° d ONLN d V Ø H ∑ b ( µ HRESUL èU ° d ONLN d [ Ø b ∑ Ü )T CODES ,
Courier
. ° d ONLN d c Ω ä … ® +(noErr ° d ONLN d i æ … )å0 . ° d ONLN d k æ/ …K )No err E† ° d ONLN d q æL …U ) or . ° d ONLN d t » ä ‘ ¿ ( — ä statusErr . ° d ONLN d ~ … ‘ )Ç–18 ° d ONLN d Ç …/ ‘j )#Driver can’t r ã ° d ONLN d ê …j ‘À );espond to this status r ≤@ ° d ONLN d ß …À ‘Á )aequest . ° d ONLN d Æ ” ä fl Δ ( ‹ ä
badUnitErr . ° d ONLN d π ‘ fl )Ç–21 ° d ONLN d Ω ‘/ flF )#Refer ⁄ ° d ONLN d ¬ ‘F flÒ )&ence number out of range or not in use . ° d ONLN d È fi ä Í “ ( Á ä unitEmptyErr . ° d ONLN d ˆ fl Í )Ç–22 ° d ONLN d ˙ fl/ Íü )#DCE points to null driver . ° d ONLN d È ä ı Δ ( Ú ä
notOpenErr . ° d ONLN d Í ı )Ç–26 ° d ONLN d# Í/ ız )#Driver isn’t open
° d ONLN d5 H o ( HSEE ALSO
° d ONLN d> ä)1 +B&For information about the high-level r ° d ONLN dd 2)¬ )® outine for terminating pending r ¿ ° d ONLN dÑ ¡)˚ )èequests for a . ° d ONLN dí* ä5 ß (2 ädriver ¬† ° d ONLN dò* ¶5 ⁄ ) , see the pr ï ° d ONLN d§* ⁄5 )4$evious section, which describes the ï ° d ONLN d»)5£ )•KillIO ï ° d ONLN dŒ*£5Õ )$
function.
I Hd 4J Hd
u H} 4v H} v Hv
ˇ·ˇ‚7^
ˇˇ£‰ . ˇÆ ° d ONLN dŸb HtD (p H Summary of the Device Manager ˇˇˇˇˇˇ ⁄| (p 1
. ° d ONLN dÿ‰ H f *CONST ° d ONLN dflÚ T˛ Δ + {Positioning modes} ° d ONLN dÙ T ä * fsAtMark ° d ONLN d˝ ä ñ )6 ° d ONLN dˇ ñ ∫ ) = 0; ° d ONLN d Ü )r{at current position} ° d ONLN d% H N ( H ° d ONLN d& N T ) ° d ONLN d' T ® )fsFromStart = ° d ONLN d5 ® ∫ )T1; ° d ONLN dCí )`{offset from beginning} ° d ONLN d[ H( N (% H ° d ONLN d\ N( T ) ° d ONLN d] T( ú ) fsFromMark ° d ONLN di ú( ∫ )H= 2; ° d ONLN dy (º )l {offset from current position} ° d ONLN dô4 T@ ú (= T {Read modes} ° d ONLN dßB TN ä * rdVerify ° d ONLN d∞B äN ñ )6 ° d ONLN d≤B ñN ∫ ) = 64; ° d ONLN d¬BNt )r{read-verify mode} ˇÄ @ ˇ ˇˇˇˇ @
° d ONLN d \ * i M ( f *Data T ˘@ ° d ONLN d \ L i d )"ypes ,
Courier
. ° d ONLN d u 6 ŧ ( ~ 6=ParamBlkType = {ioParam, fileParam, volumeParam, cntrlParam}; ° d ONLN d L ë 6 ù ñ * ParamBlockRec = ° d ONLN d ^ ü 6 ´ Z *RECORD ° d ONLN d g ≠ H π l +qLink: ° d ONLN d r ≠ ¢ π ÿ )Z QElemPtr; ° d ONLN d ≠ Í πV )H{next queue entry} ° d ONLN d î ª H « l ( ƒ HqType: ° d ONLN d ü ª ¢ « “ )ZInteger; ° d ONLN d ´ ª Í «2 )H {queue type} ° d ONLN d ∫ … H ’ r ( “ HioTrap: ° d ONLN d Δ … ¢ ’ “ )ZInteger; ° d ONLN d “ … Í ’> )H{routine trap} ° d ONLN d „ ◊ H „ Ñ ( ‡ H
ioCmdAddr: ° d ONLN d Ú ◊ ¢ „ ∫ )ZPtr; ° d ONLN d ˙ ◊ Í „P )H{routine address} ° d ONLN d  H Ò ñ ( Ó H
ioCompletion: ° d ONLN d  ¢ Ò “ )ZProcPtr; ° d ONLN d, Â Í Òb )H{completion routine} ° d ONLN dC Û H ˇ ~ ( ¸ H ioResult: ° d ONLN dQ Û ¢ ˇ Δ )ZOSErr; ° d ONLN d[ Û Í ˇ8 )H
{result code} ° d ONLN dk H
Ñ (
H
ioNamePtr: ° d ONLN dz ¢
fi )Z
StringPtr; ° d ONLN dà Í
8 )H
{driver name} ° d ONLN dò H ~ ( H ioVRefNum ° d ONLN d¢ ~ Ñ )6: ° d ONLN dß ¢ “ )$Integer; ° d ONLN d≥ Í∂ )H"{volume reference or drive number} ° d ONLN dÿ H) ¿ (& HCASE ParamBlkType OF ° d ONLN d+ Z7 ä +ioParam: ° d ONLN d¸9 ZE ` * ° d ONLN d˛9 lE ® )
(ioRefNum: ° d ONLN d 9 ¥E Í )H Integer; ° d ONLN d9E§ )Z{driver reference number} ° d ONLN d8G lS Æ (P l ioVersNum: ° d ONLN dGG ¥S ¸ )H SignedByte; ° d ONLN dXGSJ )Z
{not used} ° d ONLN dgU la Æ (^ l ioPermssn: ° d ONLN dvU ¥a ¸ )H SignedByte; ° d ONLN dáUaò )Z{read/write permission} ° d ONLN d£c lo ú (l l ioMisc: ° d ONLN dØc ¥o “ )H Ptr; ° d ONLN dπcoJ )Z
{not used} ° d ONLN d»q l} ® (z l
ioBuffer: ° d ONLN d÷q ¥} “ )H Ptr; ° d ONLN d‡q}û )Z{pointer to data buffer} ° d ONLN d˝ lã ¥ (à l ioReqCount: ° d ONLN d
. ° d ONLN d j H v Æ ( s HFUNCTION OpenSlot ° d ONLN d j Ú vÇ )™(paramBlock: ParmBlkPtr; ° d ONLN d 1 x Ú ÑÇ * async: Boolean): OSErr; ° d ONLN d J î H † ¿ ( ù HFUNCTION CloseDriver ° d ONLN d h î Ú †à )™(refNum: Integer): OSErr; ° d ONLN d Ç ∞ H º ® ( π HFUNCTION PBClose ° d ONLN d ö ∞ Ú ºÇ )™(paramBlock: ParmBlkPtr; ° d ONLN d ¥ æ Ú Ç * async: Boolean): OSErr;
. ° d ONLN d Õ ‹ H Ë ≤ ( Â HReading From and W wß ° d ONLN d fl ‹ ≤ Ë ◊ )jriting T {ö ° d ONLN d Á ‹ ◊ Ë* )%o Device Drivers
. ° d ONLN d ¯ Ô H ˚ ¢ ( ¯ HFUNCTION FSRead ° d ONLN d Ô Ú ˚X )™(refNum: Integer; ° d ONLN d! ˝ Ú j * VAR count: LongInt; ° d ONLN d7 Úv * buffPtr: Ptr): OSErr; ° d ONLN dN' H3 ¢ (0 HFUNCTION PBRead ° d ONLN db' Ú3Ç )™(paramBlock: ParmBlkPtr; ° d ONLN d{5 ¯AÇ +async: Boolean): OSErr; ° d ONLN dìQ H] ® (Z HFUNCTION FSWrite ° d ONLN d§Q Ú]X )™(refNum: Integer: ° d ONLN dæ_ ¯kj +VAR count: LongInt; ° d ONLN d⁄m ¯yv *buffPtr: Ptr): OSErr; ° d ONLN dâ Hï ~ (í H FUNCTION ° d ONLN d˘â ~ï ® )6PBWrite ° d ONLN dâ ÚïÇ )t(paramBlock: ParmBlkPtr; ° d ONLN d"ó ¯£Ç +async: Boolean): OSErr;
. ° d ONLN d:µ H¡# (æ H)Controlling and Monitoring Device Drivers
. ° d ONLN dd» H‘ ® *FUNCTION Control ° d ONLN d}» Ú‘X )™(refNum: Integer; ° d ONLN dò÷ ¯‚X +csCode: Integer; ° d ONLN d≤‰ ¯à *csParamPtr: Ptr): OSErr; ° d ONLN dÀ H ~ ( H FUNCTION ° d ONLN d‘ ~ ¥ )6 PBControl ° d ONLN dfi Ú Ç )t(paramBlock: ParmBlkPtr; ° d ONLN dˇ ¯Ç +async: Boolean): OSErr; ° d ONLN d* H6 ¢ (3 HFUNCTION Status ° d ONLN d/* Ú6X )™(refNum: Integer; ° d ONLN dI8 ¯DX +csCode: Integer; ° d ONLN daF ¯Rà *csParamPtr: Ptr): OSErr; ° d ONLN dzb Hn Æ (k HFUNCTION PBStatus ° d ONLN dåb ÚnÇ )™(paramBlock: ParmBlkPtr; ° d ONLN d≠p ¯|Ç +async: Boolean): OSErr; ° d ONLN d≈å Hò ® (ï HFUNCTION KillIO ° d ONLN d›å Úòà )™(refNum: Integer): OSErr; ˇ
. ° d ONLN d \ * h ` ( e * FUNCTION ° d ONLN d \ ` h ê )6PBKillIO ° d ONLN d \ ‘ hd )t(paramBlock: ParmBlkPtr; ° d ONLN d 3 j ⁄ vd +async: Boolean): OSErr;
. ° d ONLN d X ± * Ω H *noErr . ° d ONLN d ^ ≤ á Ω å )]0 ° d ONLN d ` ≤ ü Ω Ω )No Err ó¿ ° d ONLN d f ≤ Ω Ω Δ ) or . ° d ONLN d i Ω * … f ( Δ *
controlErr . ° d ONLN d t æ } … å )S–17 ° d ONLN d x æ ü … ⁄ )"Driver can’t r ã ° d ONLN d Ü æ ⁄ …1 );espond to this contr %‡ ° d ONLN d ö æ2 …@ )Xol r »¿ ° d ONLN d û æ@ …\ )equest . ° d ONLN d • … * ’ ` ( “ * statusErr . ° d ONLN d Ø } ’ å )S–18 ° d ONLN d ≥ ü ’ ⁄ )"Driver can’t r ã ° d ONLN d ¡ ⁄ ’; );espond to this status r ≤@ ° d ONLN d ÿ ; ’W )aequest . ° d ONLN d fl ’ * · T ( fi *readErr . ° d ONLN d Á ÷ } · å )S–19 ° d ONLN d Î ÷ ü · ⁄ )"Driver can’t r ã ° d ONLN d ˘ ÷ ⁄ · ); espond to r s@ ° d ONLN d ÷ ·" )2ead r ù† ° d ONLN d ÷" ·B )equests . ° d ONLN d · * Ì T ( Í *writErr . ° d ONLN d ‚ } Ì å )S–20 ° d ONLN d ‚ ü Ì ⁄ )"Driver can’t r ã ° d ONLN d+ ‚ ⁄ Ì% );espond to write r 1@ ° d ONLN d< ‚& ÌF )Lequests . ° d ONLN dD Ì * ˘ f ( ˆ *
badUnitErr . ° d ONLN dO Ó } ˘ å )S–21 ° d ONLN dS Ó ü ˘ ∂ )"Bad r ¸Ä ° d ONLN dX Ó ∂ ˘ Δ )efer ®† ° d ONLN d\ Ó « ˘ ) ence number . ° d ONLN dh ˘ * r ( * unitEmptyErr . ° d ONLN du ˙ } å )S–22 ° d ONLN dy ˙ ü ∂ )"Bad r ¸Ä ° d ONLN d~ ˙ ∂ Δ )efer ®† ° d ONLN dÇ ˙ « ) ence number . ° d ONLN dé * T ( *openErr . ° d ONLN dñ } å )S–23 ° d ONLN dö ü )"Driver can’t perform r Y` ° d ONLN d∞/ )b
equested r 6† ° d ONLN d∫/| ).eading or writing . ° d ONLN dà * Z ( *dInstErr . ° d ONLN d’ } å )S–26 ° d ONLN dŸ ü Œ )"
Couldn’t fi Ä ° d ONLN d‰ œ
)0nd driver in r ƒ† ° d ONLN dÚ
" );esour ‡ ° d ONLN d˜# 4 )ce fi ”Ä ° d ONLN d¸4 ; )le . ° d ONLN dˇ *) ` (& * dRemovErr . ° d ONLN d }) å )S–26 ° d ONLN d
ü) ’ )" Attempt to r + ° d ONLN d ÷)7 )7emove an open driver . ° d ONLN d.) *5 f (2 *
notOpenErr . ° d ONLN d9* }5 å )S–26 ° d ONLN d=* ü5 Í )"Driver isn’t open . ° d ONLN dO5 *A Z (> *abortErr . ° d ONLN dX6 }A å )S–27 ° d ONLN d\6 üA )"Request aborted by KillIO . ° d ONLN dvA *M H (J *ioErr ° d ONLN d|B }M å )S–36 . ° d ONLN dÄB üM )"Data doesn’t match in r …@ ° d ONLN dóBMO )gead-verify mode ˇ@ @ ˇ ˇˇˇˇ @
ˇ·ˇ‚7^
4 H \ , Palatino
. +ä"CHAPTER œ´ )\1 , Helvetica
( @ äThe Device Manager 4⁄ ä˙ (‡ ä Summary of the Device Manager
° d ONLN d \ H i ¯ ( f H Assembly-Language Information
° d ONLN d H ã Ô *" Device Manager Parameter Block
° d ONLN d > ç m ò r +%
0 ,
Courier . ° d ONLN d @ å ä ò ® ) qLink . ° d ONLN d F ç fi òâ )T%used internally by the Device Manager ° d ONLN d n ô m § r ( ° m4 . ° d ONLN d p ò ä § ® ) qType . ° d ONLN d v ô fi §â )T%used internally by the Device Manager ° d ONLN d û • m ∞ r ( ≠ m6 . ° d ONLN d † § ä ∞ Æ ) ioTrap . ° d ONLN d ß • fi ∞â )T%used internally by the Device Manager ° d ONLN d œ ± m º r ( π m8 . ° d ONLN d — ∞ ä º ¿ ) ioCmdAddr . ° d ONLN d € ± fi ºâ )T%used internally by the Device Manager , Symbol ° d ONLN dˇˇ ( ≈ HÆ ° d ONLN dˇˇ )%12 . ° d ONLN dˇˇ ) ioCompletion . ° d ONLN dˇˇ )T completion r §Ä ° d ONLN dˇˇ )8outine ° d ONLN dˇˇ ( — H¨ ° d ONLN dˇˇ )%16 . ° d ONLN dˇˇ ) ioResult . ° d ONLN dˇˇ )Tr E ° d ONLN dˇˇ )
esult code ° d ONLN dˇˇ ( › HÆ ° d ONLN dˇˇ )%18 . ° d ONLN dˇˇ ) ioNamePtr . ° d ONLN dˇˇ )T driver name ° d ONLN dˇˇ ( È HÆ ° d ONLN dˇˇ )%22 . ° d ONLN dˇˇ ) ioVRefNum . ° d ONLN dˇˇ )T drive number ° d ONLN dˇˇ ( HÆ ° d ONLN dˇˇ )%24 . ° d ONLN dˇˇ ) ioRefNum . ° d ONLN dˇˇ )Tdriver r @ ° d ONLN dˇˇ )"efer ` ° d ONLN dˇˇ ) ence number ° d ONLN dˇˇ (
m26 . ° d ONLN dˇˇ ) ioVersNum . ° d ONLN dˇˇ )Tnot used ° d ONLN dˇˇ ( HÆ ° d ONLN dˇˇ )%28 . ° d ONLN dˇˇ ) ioPermssn . ° d ONLN dˇˇ )Tr E ° d ONLN dˇˇ )ead/write permission ° d ONLN dˇˇ (% m30 . ° d ONLN dˇˇ ) ioMisc . ° d ONLN dˇˇ )Tnot used ° d ONLN dˇˇ (1 HÆ ° d ONLN dˇˇ )%32 . ° d ONLN dˇˇ ) ioBuffer . ° d ONLN dˇˇ )Tpointer to data buf ˚ ° d ONLN dˇˇ )Rfer ° d ONLN dˇˇ (= HÆ ° d ONLN dˇˇ )%36 . ° d ONLN dˇˇ )
ioReqCount . ° d ONLN dˇˇ )Tr E ° d ONLN dˇˇ )equested number of bytes ° d ONLN dˇˇ (I H¨ ° d ONLN dˇˇ )%40 . ° d ONLN dˇˇ )
ioActCount . ° d ONLN dˇˇ )Tactual number of bytes ° d ONLN dˇˇ (U HÆ ° d ONLN dˇˇ )%44 . ° d ONLN dˇˇ ) ioPosMode . ° d ONLN dˇˇ )Tpositioning mode ° d ONLN dˇˇ (a H´ ° d ONLN dˇˇ )%46 . ° d ONLN dˇˇ ) ioPosOffset . ° d ONLN dˇˇ )Tpositioning of Û@ ° d ONLN dˇˇ )=fset ° d ONLN dˇˇ (y HÆ ° d ONLN dˇˇ )%24 . ° d ONLN dˇˇ ) ioCRefNum . ° d ONLN dˇˇ )Tdriver r @ ° d ONLN dˇˇ )"efer ` ° d ONLN dˇˇ ) ence number ° d ONLN dˇˇ (Ö HÆ ° d ONLN dˇˇ )%26 . ° d ONLN dˇˇ ) csCode . ° d ONLN dˇˇ )T
for OpenSlot ° d ONLN dˇˇ (Õ HÆ ° d ONLN dˇˇ )%34 . ° d ONLN dˇˇ ) ioSlot . ° d ONLN dˇˇ )T slot number ° d ONLN dˇˇ (Ÿ HÆ ° d ONLN dˇˇ )%35 . ° d ONLN dˇˇ ) ioId . ° d ONLN dˇˇ )Tslot r ¢@ ° d ONLN dˇˇ )esour ÍÄ ° d ONLN dˇˇ )ce ID ° d ONLN dˇˇ (Ò HÆ ° d ONLN dˇˇ )%34 . ° d ONLN dˇˇ )
ioSEBlkPtr . ° d ONLN dˇˇ )T#pointer to external parameter block
° d ONLN dˇˇ (* HT †À ° d ONLN dˇˇ )
rap Macros
° d ONLN dˇˇ (@ HT Ä– ° d ONLN dˇˇ ) rap Macro ° d ONLN dˇˇ )uT Ä– ° d ONLN dˇˇ )rap W V¿ ° d ONLN dˇˇ )ord
° d ONLN dˇˇ (O H_Open ° d ONLN dˇˇ )z$A000 ° d ONLN dˇˇ (_ H_Close ° d ONLN dˇˇ )z$A001 ° d ONLN dˇˇ (o H_Read ° d ONLN dˇˇ )z$A002 ° d ONLN dˇˇ ( H_W ¬† ° d ONLN dˇˇ )rite ° d ONLN dˇˇ )l$A003 ° d ONLN dˇˇ (è H_Contr Â@ ° d ONLN dˇˇ ) ol ° d ONLN dˇˇ )\$A004 ° d ONLN dˇˇ (ü H_Status ° d ONLN dˇˇ )z$A005 ° d ONLN dˇˇ (Ø H_KillIO ° d ONLN dˇˇ )z$A006 ˇ» @ ˇ ˇˇˇˇ @
1 ° d ONLN d´ Œ∂ ÿ (≥ ŒW ¬† ° d ONLN d´ ◊∂4 ) riting the Prime Subr ú ° d ONLN d ´4∂P )]outine fi` ° d ONLN d$´d∂v )02-14 ° d ONLN d)∏ Œ√ ÿ (¿ ŒW ¬† ° d ONLN d*∏ ◊√ ) riting the Contr kÄ ° d ONLN d:∏ √l )Eol and Status Subr “† ° d ONLN dL∏l√å )Poutines R ° d ONLN dU∏°√≥ )52-15 ° d ONLN dZ≈ ƒ– (Õ ƒ
Handling I/O € ° d ONLN dg≈–) )@Asynchr F` ° d ONLN dn≈*–M )&onously æ` ° d ONLN dw≈a–s )72-18 ° d ONLN d|“ ƒ› (⁄ ƒInstalling the Driver ! ° d ONLN dì“2›D )n2-19 ° d ONLN dòfl ∫Í ƒ (Á ∫W ¬† ° d ONLN dôfl √Í
ÍÅ )G-Compatible Device Driver ,‡ ° d ONLN dƒflñÍ® )å2-22 ° d ONLN d…Ï ƒ˜ (Ù ƒHow the Chooser W ‹‡ ° d ONLN d⁄Ï ˜0 )Yorks ° d ONLN d‡ÏE˜W )(2-22 ° d ONLN d¢ ƒ œ ( ƒCr \ ° d ONLN dÁ˘ œY ) eating a Chooser Extension File 5 ° d ONLN d˘nÄ )ü2-25 ° d ONLN d
ƒ œ ( ƒCr \ ° d ONLN d œ9 ) eating a Device Package ‚ ° d ONLN d(M_ )~2-27 ° d ONLN d- ƒ < ( ƒResponding to the Chooser ƒ ° d ONLN dHP b )å2-29 ° d ONLN dM ƒ+6 (( ƒAllocating private storage X† ° d ONLN di K+] )á2-32 ° d ONLN dn- ∫8 ƒ (5 ∫W ¬† ° d ONLN do- √8 ˛ ) riting a Desk ùÄ ° d ONLN d}- ˛8* ); Accessory Ä ° d ONLN dà-?8Q )A2-33 ° d ONLN dç: ƒE ı (B ƒ How Desk íÄ ° d ONLN dñ: ıE4 )1
Accessories W j ° d ONLN d£:4EB )?ork a@ ° d ONLN d®:WEi )#2-33 ° d ONLN d≠G ƒR œ (O ƒCr \ ° d ONLN dØG œR2 ) eating a Driver Resour !‡ ° d ONLN d≈G3Rn )dce for a Desk ` ° d ONLN d”GnRö ); Accessory Ô ° d ONLN dfiGÆR¿ )@2-34 ° d ONLN d„T ƒ_E (\ ƒOpening and Closing a Desk û` ° d ONLN d˛TE_q )Å Accessory Å ° d ONLN d TÜ_ò )A2-34 ° d ONLN da ƒl$ (i ƒResponding to Events vÄ ° d ONLN d$a9lK )u2-35 ° d ONLN d)n ∫y — (v ∫Refer ⁄ ° d ONLN d.n —y ‰ )ence Ø ° d ONLN d4n ˘y )(2-36 ° d ONLN d9{ ƒÜ Á (É ƒData Str `` ° d ONLN dA{ ËÜ ˇ )$uctur Ê@ ° d ONLN dF{ ˇÜ )es χ ° d ONLN dJ{ Ü. ) 2-36 ° d ONLN dOà ŒìH (ê ŒThe Extended Device Contr ì@ ° d ONLN dhàHìk )zol Entry "` ° d ONLN dràÄìí )82-37 ° d ONLN dwï ƒ† Î (ù ƒRoutines ≠` ° d ONLN dÅï ˇ† );2-38 ° d ONLN dÜ¢ ƒ≠ „ (™ ƒResour v@ ° d ONLN då¢ „≠ ) ces Ì ° d ONLN dë¢≠ )!2-41 ° d ONLN dñØ ∫∫  (∑ ∫Summary † ° d ONLN düØ ˘∫ )?2-43 ˇå @ ˇ ˇˇˇˇ @
ˇˇ—Ú ˇÆ ° d ONLN d 8 ä C í ( @ äW ßÇ ° d ONLN d 8 í C ¶ )riting ;@ ° d ONLN d 8 ß C ¨ )Y :r ° d ONLN d 8 ¨ C )our Own Device Driver ˇˇˇˇˇˇ ≠> ( @2
° d ONLN d ] ä hk ( e ä3This chapter describes how to write a device driver ≥@ ° d ONLN d R ]k h )·%, how your device driver can use the ° d ONLN d w i ä t Æ ( q äChooser è@ ° d ONLN d ~ i Æ t≥ )$:, and how to make your device driver into a desk accessory ' ° d ONLN d ∏ i≥ tµ ( q≥. ° d ONLN d ∫ { ä Ü ( É äUAlthough this chapter describes some of the internal mechanisms of the Device Manager ≤† ° d ONLN d { Ü ( É, ° d ONLN d á ä í „ ( è äyou do not need to r #Ä ° d ONLN d% á ‰ í )Z:ead this chapter if you want to use the Device Manager to ° d ONLN d_ ì ä û ¯ ( õ äcommunicate with an alr ú¿ ° d ONLN dv ì ¯ ûp )neady-existing device driver Q¿ ° d ONLN dë ìp ûÛ )x . See the chapter “The Device ° d ONLN dØ ü ä ™ € ( ß äManager” instead. ° d ONLN d¡ ± ä ºZ *.If you do want to write your own device driver ñ ° d ONLN dÔ ±Z º˘ )–%, or just learn about how the Device ° d ONLN d Ω ä »q ( ≈ ä3Manager interacts with device drivers, you should fi ¯‡ ° d ONLN dH Ωq »Ç )Árst r ؇ ° d ONLN dM ΩÉ » ) ead the chapter “The Device ° d ONLN di … ä ‘ Ê ( — äManager” and then r Ú‡ ° d ONLN d| … Ê ‘, )\ead this chapter ñ` ° d ONLN då …, ‘. )F. ° d ONLN dé € ä Ê ( „ ä This chapter shows how you can ,
Zapf Dingbats
° d ONLN d≠ Ô ä ˆ è *n
° d ONLN dØ Ì ñ ¯ û ) cr µ@ ° d ONLN d± Ì û ¯ )eate a device driver that r - ° d ONLN dÃ Ì ¯ê )qesponds to Device Manager r 3¿ ° d ONLN dÁ Ìê ¯∞ )Åequests
° d ONLN dÔ ä è ( än
° d ONLN dÒ ˇ ñ
ü ) pr G ° d ONLN dÛ ˇ †
ë )
7ovide a user interface for your driver with the Chooser
° d ONLN d+ ä è ( än
° d ONLN d- ñ û ) cr µ@ ° d ONLN d/ û ˚ )eate a desk accessory ° d ONLN dE# ä. ê (+ äY @Ä ° d ONLN dF# ê. ¬ ) ou should r @ ° d ONLN dQ# √. Î )3 ead the fi ‡¿ ° d ONLN d[# Î.Y )(rst section of this chapter ¬¿ ° d ONLN dv#Y. )n', which describes how to write a basic ° d ONLN dù/ ä: ƒ (7 ä
device driver I¿ ° d ONLN d™/ ƒ: ‡ ):, befor )` ° d ONLN d±/ ‡: Î ) e r 8 ° d ONLN d¥/ Î:› ) 7eading the sections on the Chooser or desk accessories.
? HZ 4@ HZ
k Hs 4l Hs l Hl
ˇ·ˇ‚7^
ˇˇ£‰ ˇÆ ° d ONLN dÏX Hj X (f HW œ ° d ONLN dÌX Xj ˜ )riting a Device Driver ˇˇˇˇˇˇ ⁄| (f 2
° d ONLN d| äጠ(Ñ äHThis section shows you how to write a basic device driver—one that can r I ° d ONLN dL|œá˝ (Ñœ
or a¿ ° d ONLN dÿîtüÉ )“W §` ° d ONLN d⁄îÇüΩ )riting a Desk @ ° d ONLN dËîΩüˇ );Accessory” on ° d ONLN dˆ† ä´ ™ (® äpage 2- Æ¿ ° d ONLN d˝† ™´ ¥ ) 31 Æ¿ ° d ONLN dˇ† ¥´ π )
. ° d ONLN d≤ äΩ ê (∫ äT µ¿ ° d ONLN d≤ èΩ Ú )o write a device driver ≥ ° d ONLN d≤ ÚΩI )c, you need to know
° d ONLN d.Δ äÕ è (Ã än
° d ONLN d0ƒ ñœò ) 8how the Device Manager opens drivers, maintains data str ≈Ä ° d ONLN dhƒòœØ (Ãòuctur K` ° d ONLN dmƒ∞œ )es about them, and ° d ONLN dÄ– ñ€ (ÿ ñcommunicates with them
° d ONLN dó‰ äÎ è (Í än
° d ONLN dô‚ ñÌ ø ) how to cr ° d ONLN d¢‚ ¿Ì ˝ )*eate a driver r ~‡ ° d ONLN d±‚ ˝Ì )=esour « ° d ONLN d∂‚Ì )ce
° d ONLN dπˆ ä˝ è (¸ än
° d ONLN dªÙ ñˇ ) how the code in your driver r ú¿ ° d ONLN dÿÙˇ0 )Çesour  ° d ONLN d›Ù0ˇ` ) ce should r s ° d ONLN dËÙaˇ› )1espond to Device Manager r <† ° d ONLN dÙfiˇ˛ )}equests ° d ONLN d
äI ( ä+The next few sections examine these topics.
6 H< 47 H< 7 ä7
ˇ·ˇ‚7^
ˇˇ◊ ˇ◊ ° d ONLN d6& ä6O *$How the Device Manager W fi ° d ONLN dN&N6k )ƒorks ˇˇˇˇˇˇ • )¿2
° d ONLN dS= äH‘ (E äGThe Device Manager communicates with device drivers by calling one of fi √Ä ° d ONLN dõ=‘H‡ (E‘ve ≥` ° d ONLN dû=·Hˇ )
driver ° d ONLN d•I äT ¿ (Q ä subroutines Í ° d ONLN d∞I ¿T )6: Open, Prime, Contr JÄ ° d ONLN dƒI Tz )\ol, Status, and Close. ;@ ° d ONLN d€IzT )^ All drivers must have an Open ° d ONLN d˘U ä` à (] äand Close subr y` ° d ONLN dU Ã`6 )Boutine; the Prime, Contr † ° d ONLN d U7`â )kol, and Status subr  ° d ONLN d2Uà`≥ )Q
° d ONLN d \ l g ÷ ( d lDevice Manager routines ° d ONLN d \ ¸ g} )ê Responsible driver subroutine ,
Courier
ˇ˝ˇ¸ . ° d ONLN d 7 j l v ® ( s l
OpenDriver ˇ˛ˇ˛ ¬† ° d ONLN d A k ß v ´ );, ˇ˝ˇ¸ ¬û ° d ONLN d C j ¨ v – )PBOpen ˇ˛ˇ˛ ¬û ° d ONLN d I k – v ‘ )$, ˇ˝ˇ¸ ¬ú ° d ONLN d K j ’ v )OpenSlot . ° d ONLN d U k& v> )QOpen ˇ˝ˇ¸ . ° d ONLN d Z z l Ü ê ( É lFSRead ˇ˛ˇ˛ ° d ONLN d ` { ê Ü î )$, ˇ˝ˇ¸ ˛ ° d ONLN d b z ï Ü π )PBRead . ° d ONLN d j {& Ü@ )ëPrime . ° d ONLN d p ä l ñ à ( ì lFSWrite, PBWrite . ° d ONLN d Ç ã& ñ@ )∫Prime ˇ˝ˇ¸ . ° d ONLN d à ö l ¶ ê ( £ lStatus ˇ˛ˇ˛ ° d ONLN d é õ ê ¶ î )$, ˇ˝ˇ¸ ˛ ° d ONLN d ê ö ï ¶ ≈ )PBStatus . ° d ONLN d ö õ& ¶A )ëStatus ˇ˝ˇ¸ . ° d ONLN d ° ™ l ∂ ñ ( ≥ lControl ˇ˛ˇ˛ ° d ONLN d ® ´ ñ ∂ ö )*, ˇ˝ˇ¸ ˛ ° d ONLN d ™ ™ õ ∂ — ) PBControl . ° d ONLN d µ ´& ∂? )ãContr Â@ ° d ONLN d ∫ ´? ∂G )ol ˇ˝ˇ¸ . ° d ONLN d Ω ∫ l Δ ê ( √ lKillIO ˇ˛ˇ˛ ° d ONLN d √ ª ê Δ î )$, ˇ˝ˇ¸ ˛ ° d ONLN d ≈ ∫ ï Δ ≈ )PBKillIO . ° d ONLN d œ ª& Δ? )ëContr Â@ ° d ONLN d ‘ ª? ΔG )ol ˇ˝ˇ¸ . ° d ONLN d ÿ l ÷ Æ ( ” l CloseDriver ˇ˛ˇ˛ ¬† ° d ONLN d „ À ≠ ÷ ± )A, ˇ˝ˇ¸ ¬û ° d ONLN d  ≤ ÷ ‹ )PBClose . ° d ONLN d Ó À& ÷> )tClose
„ * ¯ 4 ‰ * Ô¯
° d ONLN dˇˇ ( Î lNOTE
ˇ·ˇ‚7^
° d ONLN d Ù Ó l ˘ Œ * The Device Manager r b ° d ONLN d Ó Œ ˘ ˘ )b
outines ar &Ä ° d ONLN d Ó ˙ ˘í ),$e listed by their actual names. The ° d ONLN d6 ˙ l } ( lcorr ` ° d ONLN d: ˙ ~ ‡ )esponding driver subr ª† ° d ONLN dO ˙ ‡& )boutine names ar o ° d ONLN d^ ˙'É )Ge descriptive names. ¡` ° d ONLN ds ˙Éâ )\Y Ň ° d ONLN dt ˙âñ )ou ° d ONLN dw l1 ( l,can choose any name for your actual driver r ? ° d ONLN d£2ç )Δoutines—the Device ° d ONLN d∂ l Û ( l Manager locates them using of @ ° d ONLN d” Ù ' )à fsets you pr ∞ ° d ONLN dfl' B )3ovide. ,
Zapf Dingbats
Ä ° d ONLN dˇˇ )"u
ˇˇ’U . ° d ONLN d˚* l5Y (2 l1When an application or another manager calls the ˇˇ™™ *® ° d ONLN d,)Z5ñ )Ó
OpenDriver ˇˇ’U *® ° d ONLN d6*ñ5¯ )< function, the Device . ° d ONLN dL6 lA ® (> l Manager sear ]† ° d ONLN dX6 ®Aá )<6ches the unit table to see if a driver with the specifi >¿ ° d ONLN dè6àA≈ )‡ed name is alr ‡ ° d ONLN dù6≈A‹ )=eady ° d ONLN d¢B lM› (J lQopen. If no open driver has a matching name, the Device Manager opens the driver ° d ONLN dÛN lY o * r E ° d ONLN dÙN pY à )esour ç@ ° d ONLN d˘N àY ◊ )ce with the specifi ¿ ° d ONLN d N ◊Y )O
ed name. T Ô‡ ° d ONLN dNYT )0o open a driver fr Í ° d ONLN d(NTYp )Mom a r ¯† ° d ONLN d.NpYà ) esour @‡ ° d ONLN d3NâYÔ )ce, the Device Manager
° d ONLN dJb li q (h ln
° d ONLN dL` xk fi ) loads the driver code fr Q@ ° d ONLN dd` flk )gom the r = ° d ONLN dl`k )%esour Ö` ° d ONLN dq` ka )ce into memory
° d ONLN dÄt l{ q (z ln
° d ONLN dÇr x} Ä ) cr µ@ ° d ONLN dÑr Ä} ÷ )eates a device contr ¥@ ° d ONLN dòr ÷} )Vol entry for it, fi ‰¿ ° d ONLN d´r}Ç )Elling it in with values fr k@ ° d ONLN d≈rÉ}‡ )hom the header of the ° d ONLN d⁄~ xâ ô (Ü xdriver r @ ° d ONLN d‚~ öâ ≤ )"esour fÄ ° d ONLN dÁ~ ≤â Ω )ce,
° d ONLN dÎí lô q (ò ln
° d ONLN dÌê xõ ‡ ) installs the device contr ê† ° d ONLN dê ‡õˆ )hBol entry in the unit table at a location determined by the driver ° d ONLN dHú xß { (§ xr E ° d ONLN dIú |ß î )esour ç@ ° d ONLN dNú îß ™ )ce ID
° d ONLN dT∞ l∑ q (∂ ln
° d ONLN dVÆ xπ π ) calls the driver Ú ° d ONLN dfÆ ∫π Ú )B ’s Open subr ° d ONLN drÆ Ûπ )9outine. ° d ONLN dz¿ lÀ › (» lThe header of the driver r Û¿ ° d ONLN dî¿ ›À ı )qesour < ° d ONLN dô¿ ˆÀÍ )7ce contains information about the driver such as which ° d ONLN d–à l◊ ù (‘ l driver subr Í ° d ONLN d€Ã ù◊ » )1
outines ar Æ` ° d ONLN dÂÃ …◊8 ),e implemented and wher £` ° d ONLN d˚Ã8◊c )o
e the subr € ° d ONLN dÃc◊é )+
outines ar üÄ ° d ONLN dÃè◊™ ),e. See º ° d ONLN dÙ◊∫ )“Cr ò ° d ONLN dÃ∫◊fl ) eating a ° d ONLN d"ÿ l„ ™ (‡ l
Driver Resour Ò ° d ONLN d/ÿ ™„ Ë )>ce” on page 2- †Ä ° d ONLN d=ÿ È„ Ó )?5 †Ä ° d ONLN d>ÿ Ó„à )$ for the format of the driver header A‡ ° d ONLN dbÿà„ä )ö. . ° d ONLN ddÍ lı ¢ (Ú l Unlike the ° d ONLN doÈ ¢ı fi )6
OpenDriver ° d ONLN dyÍ fiı )< function, the ° d ONLN dàÈ ıB )@PBOpen ° d ONLN déÍBıY )$ and ° d ONLN dìÈYıâ )OpenSlot ° d ONLN dõÍâıÍ )0 functions expect the . ° d ONLN d±ˆ l ≠ (˛ ldriver to be alr ¿ ° d ONLN d¡ˆ ÆJ )B$eady installed. These functions sear ÿ ° d ONLN dˆJŒ )ú ch the unit table for the driver ° d ONLN dˆ–Ÿ )Ü’s ° d ONLN d l
¢ (
l device contr l` ° d ONLN d ¢
)6 ol entry and call the driver ÀÄ ° d ONLN d0
P )v ’s Open subr ŸÄ ° d ONLN d<P
n )8outine. . ° d ONLN dD l Æ ( lIf you use the ° d ONLN dS Æ “ )BPBOpen ° d ONLN dY “ · )$ or ° d ONLN d] · )OpenSlot ° d ONLN de ì )0 function to open your driver ¬† ° d ONLN dÇí µ )Å, you ar ï ° d ONLN däµ ¡ )#e r g` ° d ONLN dç¡ Û ) esponsible . ° d ONLN dò l+ É (( lfor cr Ò@ ° d ONLN dû É+ Á )eating the device contr ‡ ° d ONLN dµ Ë+ˆ )eBol entry and installing it in the unit table. Even if you use the . ° d ONLN d˜+ l7 ® (4 l
OpenDriver ° d ONLN d, ®74 )< function to install your driver ¬† ° d ONLN d!,37V )ã, you ar ï ° d ONLN d),V7b )#e r g` ° d ONLN d,,b7® ) esponsible for f 7‡ ° d ONLN d<,®7ˆ )Finding an empty . ° d ONLN dL8 lC (@ l$space in the unit table, which may r ⇠° d ONLN dp8 C )ùequir ° ° d ONLN du8 Cg )e allocating mor ª ° d ONLN dÖ8gC )G e memory for it. The section ° d ONLN d¢D lO (L l"“Installing the Driver” on page 2- ñ† ° d ONLN dƒD O
)î18 ñ† ° d ONLN dΔD
O~ )
discusses the device contr Ä ° d ONLN d·DO° )uol entry :¿ ° d ONLN dÈD†O˜ )!, the unit table, and ° d ONLN dˇP l[ ± (X lhow you can pr ≤` ° d ONLN d
P ±[ )Eoperly install your driver Ň ° d ONLN d'P [" )o. ° d ONLN d)b lm r (j lT µ¿ ° d ONLN d*b qm ∂ )o allow asynchr l† ° d ONLN d9b ∑m ÿ )Fonous r ≤ ° d ONLN d@b ÿm∞ )!0equests, the Device Manager maintains a driver r E‡ ° d ONLN dpb±mÌ )Ÿ
equests ar P@ ° d ONLN d √ u fi Ä ˛ ),e satisfi K` ° d ONLN d à u ˇ Äß )!$ed, the parameter block moves forwar R` ° d ONLN d uß Äœ )®
d in the r J@ ° d ONLN d ˙ uœ Ä )(equest queue. ° d ONLN d Å ä åu ( â ä5When the parameter block is at the beginning of the r §‡ ° d ONLN d= Åu å )Î!equest queue, the Device Manager ° d ONLN d^ ç ä ò ≈ ( ï äcalls the appr §† ° d ONLN dl ç ≈ ò );opriate driver subr Ì@ ° d ONLN d ç ò )S:outine and passes it a pointer to the parameter block and ° d ONLN dπ ô ä § Î ( ° äa pointer to the driver [‡ ° d ONLN d– ô Ï §+ )b’s device contr ÃÄ ° d ONLN dfl ô+ §M )?ol entry Ì¿ ° d ONLN dÁ ôL §N )!. ° d ONLN dÈ ´ ä ∂ ü ( ≥ äFor r º@ ° d ONLN dÓ ´ ü ∂ ˙ )eading and writing r Ÿ‡ ° d ONLN d ´ ˙ ∂“ )[0equests, the Device Manager calls the Prime subr ˆ‡ ° d ONLN d2 ´“ ∂Û )ÿoutine, ° d ONLN d: ∑ ä ¬ ¬ ( ø ä
described in ` ° d ONLN dG ∑ √ ¬ “ )9“W W ° d ONLN dI ∑ — ¬. )riting the Prime Subr 0` ° d ONLN d^ ∑. ¬ )]outine” on page 2- Ë` ° d ONLN dp ∑ ¬â )Q13 Ë` ° d ONLN dr ∑â ¬∑ )
. This subr † ° d ONLN d} ∑∏ ¬ )/outine can execute ° d ONLN dê √ ä Œ ß ( À äsynchr $ ° d ONLN dñ √ ® Œ À ) onously Ä` ° d ONLN dù √ Œ )", completing the r ‡ ° d ONLN dØ √ ŒF )N
equested r ˘ ° d ONLN dπ √E Œ´ )-eading or writing befor ¨` ° d ONLN d– √¨ Œ∑ )ge r ª ° d ONLN d” √∑ Œˆ ) eturning contr Ä ° d ONLN d· √˜ Œ
)@ol to ° d ONLN dÁ œ ä ⁄ ‚ ( ◊ äthe Device Manager Å` ° d ONLN d˘ œ ‚ ⁄ )X , or asynchr
ÛG ˛n )v equest. T ¿ ° d ONLN d Ûn ˛Ÿ )'ypically these drivers pr ‡ ° d ONLN d, ÛŸ ˛Ù )kovide ° d ONLN d2 ˇ ä
¢ ( äinterr ° d ONLN d8 ˇ £
ı )upt handlers that r ù‡ ° d ONLN dK ˇ ı
; )Respond to interr X ° d ONLN d[ ˇ<
Y )Gupts fr y† ° d ONLN db ˇY
ï )
om the driver ∑ ° d ONLN do ˇñ
ˇ )=’s device and notify the ° d ONLN dà ä| ( ä5Device Manager when the transaction is complete. See † ° d ONLN dΩ }¬ )Û“Handling I/O t† ° d ONLN dÀ ¬Á )EAsynchr ‡ ° d ONLN d“ Á )% onously” ° d ONLN d€ ä" ∑ ( ä
on page 2- u† ° d ONLN d ∏" ¬ ).17 u† ° d ONLN dÁ ¬"  )
for mor @ ° d ONLN dÔ Ê" )$
e details. ° d ONLN d˙) ä4$ (1 ä The Device Manager handles contr â ° d ONLN d)$4ã )öolling and monitoring r A ° d ONLN d1)å4 )hequests in the same way as ° d ONLN dL5 ä@ ç (= är E ° d ONLN dM5 é@ È )eading and writing r b† ° d ONLN da5 È@g )[ equests, except that for contr ¿ ° d ONLN d5h@à )olling r Á‡ ° d ONLN dá5á@Û ) equests it calls the Contr √ ° d ONLN d°5Û@˝ )lol ° d ONLN d§A äL ù (I äsubr ¿ ° d ONLN d®A ûL )outine and for monitoring r ∑‡ ° d ONLN d√ALö )y equests it calls the Status subr G@ ° d ONLN d„AõL )Ñoutine. The section ° d ONLN d˜M äX ô (U ä“W ¬† ° d ONLN d˘M òX ‹ )riting the Contr kÄ ° d ONLN d M ›X- )Eol and Status Subr “† ° d ONLN dM-XÇ )Poutines” on page 2- «† ° d ONLN d.MÉXç )V15 «† ° d ONLN d0MçXŸ )
shows how to pr ¸` ° d ONLN d@MŸX
)L ovide these ° d ONLN dLY äd ù (a äsubr ¿ ° d ONLN dPY ûd )outines for your driver f` ° d ONLN dgYd )d. ° d ONLN dik äv Ï (s äThe Device Manager r b ° d ONLN d}k Ïv@ )besponds to KillIO r = ° d ONLN dêk@vt )T equests by r † ° d ONLN dúkuv )5 emoving the parameter blocks fr ¥ ° d ONLN dªkv )èom ˇˇ⁄Ä . ° d ONLN dæw äÇ2 ( ä%the queue, calling their completion r ñ‡ ° d ONLN d„w2ÇÖ )®outines with the r ¯¿ ° d ONLN dıwÖÇ¥ )S esult code ,
Courier ˇˇµ ≠¿ ° d ONLN d vµÇ )0abortErr ˇˇ⁄Ä ` ° d ONLN dw‰Ç )/ , and then ° d ONLN dÉ äé ˝ (ã äcalling the drivers Contr R` ° d ONLN d,É ˝é )sol subr $¿ ° d ONLN d3ÉéÜ ) outine with a value of $¿ ° d ONLN dJÇÜé∂ )kkillCode $¿ ° d ONLN dRÉ∂é‹ )0 for the $¿ ° d ONLN d[Ç‹é )&csCode $¿ ° d ONLN daÉ é )$ . ° d ONLN dbè äö ∑ (ó ä parameter S† ° d ONLN dkè ∑ö º )-. & ° d ONLN dmè ºö ¬ )Y ÊÄ ° d ONLN dnè ¡ö Ê )ou can fi ±Ä ° d ONLN dwè ÁöÜ )&#nd information on handling KillIO r @ ° d ONLN döèáöµ )† equests in ¥‡ ° d ONLN d•èµöƒ ).“W ˜Ä ° d ONLN dßè√ö )riting the Contr †` ° d ONLN d∑èö )Eol ° d ONLN d∫õ ä¶ œ (£ äand Status Subr @ ° d ONLN d…õ –¶% )Foutines” on page 2- ˛@ ° d ONLN d‹õ%¶/ )U15 ˛@ ° d ONLN dfiõ/¶1 )
. ° d ONLN d‡≠ ä∏ ô (µ äIn r Ù‡ ° d ONLN d‰≠ ô∏ ˜ )esponse to a closing r ° d ONLN d˙≠ ¯∏Ù )_7equest, the Device Manager queues the parameter block, ° d ONLN d1π äƒ Ù (¡ ämaking one if necessary ≠† ° d ONLN dHπ Ûƒ7 )i. Since closing r ˙ ° d ONLN dYπ7ƒ™ )Dequests cannot be asynchr * ° d ONLN drπ´ƒ¸ )tonous, the Device ° d ONLN dÑ≈ ä– (Õ äManager sends each queued r i` ° d ONLN dü≈–d )Ñequest to the driver Õ` ° d ONLN d≥≈c–ß )U. Since the last r ä‡ ° d ONLN d≈≈®– )Eequest is the closing ° d ONLN d€— ä‹ ç (Ÿ är E ° d ONLN d‹— é‹è ):equest, the Device Manager ultimately calls the Close subr ° d ONLN d —ꋸ (Ÿêoutine. When the driver ° d ONLN d .› äË Á ( äindicates it has satisfi a¿ ° d ONLN d F› ËË+ )^ed the closing r ΩÄ ° d ONLN d V›+˸ )C.equest, the Device Manager unlocks the device ° d ONLN d ÑÈ äÙ † (Ò äcontr >Ä ° d ONLN d âÈ °Ù )Sol entry and the driver code. Note that the Device Manager does not dispose of the ° d ONLN d ‹ı ä ¿ (˝ ä device contr l` ° d ONLN d Ëı ¿ )6ol entry or even r a` ° d ONLN d ˙ı ; )L emove it fr ( ° d ONLN d
ı< å )0om the unit table. ° d ONLN d
ä æ ( ä The section $@ ° d ONLN d
% ø Œ )5“W f‡ ° d ONLN d
' ÕV ) riting the Open and Close Subr ü† ° d ONLN d
EV´ )âoutines” on page 2- î† ° d ONLN d
X¨± )V1 ° d ONLN d
Y±∂ )1 ° d ONLN d
Z∂ ) shows how your ° d ONLN d
j ä Ω ( ä driver can r fl‡ ° d ONLN d
v Ω a )3$espond to both opening and closing r u† ° d ONLN d
öb Ö )•equests.
C HI 4D HI D äD
ˇ·ˇ‚7^
ˇˇ◊ ˇ◊ ° d ONLN d
£3 äC ö (? äCr îø ° d ONLN d
•3 õC6 )eating a Driver Resour Ô ° d ONLN d
ª37CE )úce ˇˇˇˇˇˇ • )◊2
° d ONLN d
æJ äU ê (R äY @Ä ° d ONLN d
øJ êU ª )
ou will pr î` ° d ONLN d
…J ªU )+obably want to stor Ì ° d ONLN d
‹JUÅ )Ue your driver in a driver r Ê` ° d ONLN d
˜JÅUô )qesour .† ° d ONLN d
¸JöU˜ )ce, although if you ar Œ¿ ° d ONLN d J˜U˛ )]e ° d ONLN d V äaÄ (^ ä9writing a driver for a slot device you might want to stor • ° d ONLN d MVÄa )ˆ!e your driver in the declaration ° d ONLN d nb äm ˝ (j äROM of the expansion car ç ° d ONLN d Üb ˝m )sd (see Õ ° d ONLN d çbm˘ ) 4Designing Cards and Drivers for the Macintosh Family ‡ ° d ONLN d ¡b˙m )· for ˇˇEö . ° d ONLN d Δn äy õ (v ämor R` ° d ONLN d …n õy\ )-e details). Storing your driver in a driver r Qê ° d ONLN d ˆn\ys )¡esour # ° d ONLN d ˚nsy± )ce allows the ˇ˛ã4 Ùæ ° d ONLN d m±yÌ )>
OpenDriver ˇˇEö Ùæ ° d ONLN d nÌy )<
function . ° d ONLN d z äÖ¢ (Ç ä?to load your driver code into memory and install a device contr í ° d ONLN d \z¢Ö (Ç¢ol entry for your driver ° d ONLN d uÜ äë “ (é äin the unit table. ° d ONLN d àò ä£ ± *
ce has a r #‡ ° d ONLN d ∏òV£n ))esour l ° d ONLN d Ωòn£ù ) ce type, a r @ ° d ONLN d …òû£∂ )0esour PÄ ° d ONLN d Œò∂£› )
ce ID, a r k ° d ONLN d ÿò›£ı )'esour ≥` ° d ONLN d ›òı£ )ce ° d ONLN d ‡§ äØ æ (¨ ä name, and r ! ° d ONLN d Χ øØ ◊ )5esour i` ° d ONLN d § ◊Ø )ce attributes: ˇ‘ @ ˇ ˇˇˇˇ @
. ° d ONLN d ] x h ë ) The r R` ° d ONLN d ] ë h ® )esour $¿ ° d ONLN d ] ® h Ò )ce type must be ,
Courier $¿ ° d ONLN d \ Ò h )I'DRVR' $¿ ° d ONLN d " ] h )$.
. ° d ONLN d $ q l x q ( w ln
° d ONLN d & o x z è ) The r Ä¿ ° d ONLN d + o è z ß )esour … ° d ONLN d 0 o ß z )ce ID determines wher Œ ° d ONLN d E o z )d7e in the unit table the OpenSlot function installs the ° d ONLN d | { x Ü ì ( É xdriver ñ† ° d ONLN d Ç { î Ü ” ) ’s device contr @ ° d ONLN d ë { ‘ Ü ˆ )@ol entry (Ä ° d ONLN d ô { ı Ü8 )!. Unfortunately ˇ¿ ° d ONLN d ® {7 Üù )B, you must choose the r ;† ° d ONLN d ø {û Ü∂ )gesour ɇ ° d ONLN d ƒ {∂ ÜÍ ) ce ID when ° d ONLN d œ á x í Ä ( è xcr µ@ ° d ONLN d — á Ä í ◊ )eating your driver r ¶¿ ° d ONLN d  á ◊ í Ô )Wesour Ô ° d ONLN d Í á Ô í⁄ )2ce and you cannot know which unit numbers will be ° d ONLN d ì x û ( õ x$available until you open your driver T‡ ° d ONLN d@ ì û1 )†. Ther ’† ° d ONLN dF ì1 ûB )efor -† ° d ONLN dJ ìC û )e, your driver °@ ° d ONLN dX ì û≠ )<
-opening r ï† ° d ONLN db ì≠ û‰ ). outine must ° d ONLN dn ü x ™ ~ ( ß xfi å¿ ° d ONLN dp ü ~ ™p )7nd an empty location in the unit table and change the r ç‡ ° d ONLN dß üp ™à )Úesour ÷ ° d ONLN d¨ üà ™∏ ) ce ID accor F¿ ° d ONLN d∑ üπ ™’ )1dingly ° d ONLN dΩ ü’ ™Ì ) . The ° d ONLN d√ ´ x ∂ ô ( ≥ xsection ËÄ ° d ONLN dÀ ´ ô ∂- )!"“Installing the Driver” on page 2- ˇ ° d ONLN dÌ ´- ∂7 )î18 ˇ ° d ONLN dÔ ´7 ∂z )
discusses appr Ä ° d ONLN d˛ ´{ ∂€ )Dopriate values for the ° d ONLN d ∑ x ¬ { ( ø xr E ° d ONLN d ∑ | ¬ î )esour ç@ ° d ONLN d ∑ î ¬ ≠ )ce ID.
° d ONLN d" À l “ q ( — ln
ˇˇ¡œ . ° d ONLN d$ … x ‘ ê ) The r / ° d ONLN d) … ë ‘ ® )esour Êè ° d ONLN d. … ß ‘∏ ):ce name should be the same as the driver name so that the ˇˇÉû æ ° d ONLN dh »π ‘ı ( —π
OpenDriver ˇˇ¡œ æ ° d ONLN dr …ı ‘˜ )< . ° d ONLN ds ’ x ‡ ∑ ( › xfunction can fi ‹† ° d ONLN dÇ ’ ∑ ‡ ˜ )?nd the driver r E` ° d ONLN dë ’ ¯ ‡ )Aesour ç† ° d ONLN dñ ’ ‡ )ce. i ° d ONLN dö ’ ‡% )A £¿ ° d ONLN dõ ’% ‡Ì )/ driver name consists of a period (.) followed ° d ONLN d · x Ï¡ ( È xIby any sequence of 1 to 254 printing characters. The Device Manager ignor Ɔ ° d ONLN d ·¡ ψ ( È¡
es case (but ° d ONLN d Ì x ¯E ( ı x,not diacritical marks) when comparing names.
° d ONLN dM l q ( ln
° d ONLN dP ˇ x
è ) The r Ä¿ ° d ONLN dU ˇ è
ß )esour … ° d ONLN dZ ˇ ß
$ ) ce attributes of your driver r †` ° d ONLN dx ˇ$
< )}esour ˆ ° d ONLN d} ˇ<
¨ )ce depend on your driver °‡ ° d ONLN dï ˇ¨
± )p. CÄ ° d ONLN dó ˇ±
∏ )A ~ ° d ONLN dò ˇ∏
€ ) typical ° d ONLN d° x‡ ( xTdriver might have these attributes: locked, since most drivers contain code that is ° d ONLN dı x" ∏ * called at interr ¿ ° d ONLN d ∏"Ó )@Iupt time; in the system heap, so that the driver exists over launches of ° d ONLN dN# x. – (+ xapplications; and pr ® ° d ONLN db# –.8 )Xeloaded, which makes r Q‡ ° d ONLN dx#9.Q )iesour ö ° d ONLN d}#Q.∂ )ce loading slightly mor M ° d ONLN dî#∑.Δ )fe ef ܆ ° d ONLN dò#Δ.à )fi ì` ° d ONLN dö#Ã.„ )cient. ° d ONLN d°5 l@ s (= lA ∫† ° d ONLN d¢5 s@ ó ) driver r ÿ‡ ° d ONLN d´5 ó@ Ø )$esour ! ° d ONLN d∞5 ∞@ ˘ )ce has two parts:
° d ONLN d¬I lP q (O ln
° d ONLN d≈G xRx ) :a driver header that contains information about the driver
Courier . ° d ONLN d \ Ã g € )BThe ° d ONLN d \ € g? ) format of a driver header
„ HÚ 4„ HÚ . ° d ONLN dˇˇ (Í äField descriptions
ˇ·ˇ‚7^
. ° d ONLN d Ô ä˚ ¿ * drvrFlags . ° d ONLN d ( Ê˚ )\
Contains fl £¿ ° d ONLN d 3˚` )0ags in its high-or ∫ ° d ONLN d E`˚› )J der byte that specify certain ° d ONLN d c¸ Ê^ ( Ê characteristics of the driver „ ° d ONLN d ĸ]b )w. µÄ ° d ONLN d Ǹbh )Y v ° d ONLN d ɸh‡ ) ou can use the constants in `` ° d ONLN d ü¸· )y Listing 2-1 † ° d ONLN d ™¸ )/ ° d ONLN d ´ Ê" ( Êto index the fl i¿ ° d ONLN d ∫#X )=
ags in this fi µÄ ° d ONLN d »Xh )5eld. . ° d ONLN d Õ ä" ¿ ( ä drvrDelay . ° d ONLN d ◊ Ê"» )\3Indicates number of ticks between periodic actions. . ° d ONLN d % ä1 ¿ (. ä drvrEMask . ° d ONLN d& Ê1l )\ Used for desk accessories. See %` ° d ONLN d4&m1| )á“W h ° d ONLN d6&{1∂ )riting a Desk B‡ ° d ONLN dD&∂1 );Accessory” on page ° d ONLN dW2 Ê= Ó (: Ê2- ”‡ ° d ONLN dY2 Ó= ¯ )31 ”‡ ° d ONLN d[2 ¯=u )
for information about this fi W¿ ° d ONLN dy2v=Ü )~eld. . ° d ONLN d~@ äL ∫ (I ädrvrMenu . ° d ONLN dáA ÊLl )\ Used for desk accessories. See %` ° d ONLN d¶AmL| )á“W h ° d ONLN d®A{L∂ )riting a Desk B‡ ° d ONLN d∂A∂L );Accessory” on page ° d ONLN d…M ÊX Ó (U Ê2- ”‡ ° d ONLN dÀM ÓX ¯ )31 ”‡ ° d ONLN dÕM ¯Xu )
drvrStatus . ° d ONLN dØâ Êî& )\Contains an of Ñ ° d ONLN dΩâ&î¢ )@ fset to the Status driver subr (‡ ° d ONLN d€â£î¡ )}outine. . ° d ONLN d„ó ä£ ¿ († ä drvrClose . ° d ONLN dÌò Ê£& )\Contains an of Ñ ° d ONLN d˚ò&£† )@ fset to the Close driver subr õ¿ ° d ONLN dò†£æ )zoutine.
w ä… 4 w ä…
w ä…‚ 4 v â w ä ò ( ò4 ò4 w ä‚ Ÿ Ÿ =Ä˙ `Ê f˘ ``Ê aˇ˙ {w‡Ê
. ° d ONLN d \ l h ú ( e ldrvrName . ° d ONLN d ] » h= )\Contains the driver name. ° d ONLN d # ]> hD )vY œÄ ° d ONLN d $ ]C hè )ou can use upper µÄ ° d ONLN d 4 ]è h– )Lcase and lower ] ° d ONLN d B ]— h )Bcase ° d ONLN d G i » tX ( q » letters when naming your driver ˚‡ ° d ONLN d f iW tÉ )è , but the fi ∑ ° d ONLN d r iÑ tÚ )-rst character should be a . ° d ONLN d å u » Ä ( } »period— ° d ONLN d ì t Ä2 )( .YourDriver ¬† ° d ONLN d û u1 Äq )A, for example. . ° d ONLN d ≠ á l í Ø ( è lSee the section ò‡ ° d ONLN d Ω á Ø í )C“Entering and Exiting Fr F¿ ° d ONLN d ’ á ía )mom Driver Subr Ä ° d ONLN d „ áa í∂ )Eoutines” on page 2- Ä ° d ONLN d ˆ á∑ íº )V9 Ä ° d ONLN d ˜ Ạífl ) for mor fi ° d ONLN d ˇ áfl íÊ )#e ° d ONLN d ì l û „ ( õ linformation about the subr p ° d ONLN d ì „ û
)w outine of Œ@ ° d ONLN d$ ì
û )'fsets.
´ * ∏¯ 4 ¨ * ∑¯
° d ONLN dˇˇ ( ≥ lNOTE
ˇ·ˇ‚7^
° d ONLN d+ ∂ l ¡ r * Y @Ä ° d ONLN d, ∂ r ¡ • ) our driver r Œ ° d ONLN d8 ∂ • ¡S )3'outines, which follow the driver header Ú† ° d ONLN d_ ∂S ¡° )Æ, must be aligned ° d ONLN dq ¬ l Õ ì ( lon a wor X` ° d ONLN dy ¬ ì Õ « )'
d boundary KÄ ° d ONLN dÉ ¬ Δ Õ » )3. ,
Zapf Dingbats
ÀÄ ° d ONLN dˇˇ )u
* Û¯ 4 * Û¯ " *a
ˇ·ˇ‚7^
° d ONLN dˇˇ ( Ì l Listing 2-1 ° d ONLN dô  ∞ K )D'The index constants for the drvrFlags fi ‡ ° d ONLN d¡ ÂL X )úeld
. ° d ONLN d≈ ˝ l Æ ( l dReadEnable ° d ONLN d◊ ˝ ¥ Ã )H EQU ° d ONLN d› ˝ ÿ Ê )$-0 ;set if driver can respond to Read requests ° d ONLN d l Æ ( l dWritEnable ° d ONLN d ¥ Ã )H EQU ° d ONLN d# ÿÏ )$.1 ;set if driver can respond to Write requests ° d ONLN dR l% ® (" l
dCtlEnable ° d ONLN dc ¥% à )H EQU ° d ONLN di ÿ%¯ )$02 ;set if driver can respond to Control requests ° d ONLN dö' l3 à (0 ldStatEnable EQU ° d ONLN d≥' ÿ3Ú )l/3 ;set if driver can respond to Status requests ° d ONLN d„5 lA ¥ (> l dNeedGoodbye ° d ONLN dˆ5 ¥A à )H EQU ° d ONLN d¸5 ÿAÏ )$.4 ;set if driver needs to be called before the ° d ONLN d4C ÿO™ *# ; application heap is initialized ° d ONLN dXQ l] ¢ (Z l dNeedTime ° d ONLN dcQ ¢] Æ )6 ° d ONLN djQ ¥] à ) EQU ° d ONLN dpQ ÿ]‘ )$*5 ;set if driver needs time for performing ° d ONLN d§_ ÿkD * ; periodic tasks ° d ONLN d∑m ly ¢ (v l dNeedLock ° d ONLN d¬m ¢y ∫ )6 ° d ONLN dÀm ∫y à )EQU ° d ONLN d–m ÿy‡ ) ,6 ;set if driver will be locked in memory as ° d ONLN d{ ÿáb * ; soon as it's opened . ° d ONLN d î lü Ö (ú lThe fi »Ä ° d ONLN d$î Öü Æ )
rst four fl
` ° d ONLN d/î Øüc )*)ags, which occupy bits 0–3 of the high-or V ° d ONLN dXîcüÆ )¥der byte (bits 8–1 á` ° d ONLN djîÆü— )K 1 of the ˇˇˆp . ° d ONLN dsü l´ ¢ (® l drvrFlags ˇˇ˚8 ° d ONLN d|† ¢´ µ )6 wor Mò ° d ONLN dĆ ∂´a )#d), indicate which Device Manager r ° d ONLN d£†b´¥ )¨equests the driver ª‡ ° d ONLN dµ†µ´¬ )S’s r âx ° d ONLN dπ†√´˜ ) outines can . ° d ONLN d≈¨ l∑ o (¥ lr E ° d ONLN dΔ¨ p∑ Ì ) espond to. The next section, íÄ ° d ONLN d„¨ Ì∑ç )}!“Responding to the Device Manager Æ ° d ONLN d¨ç∑î )†,” . ° d ONLN d¨ï∑• ) on t‡ ° d ONLN d
¨•∑≈ )page 2- £† ° d ONLN d¨≈∑ ) 9 £† ° d ONLN d¨ ∑à ) ° d ONLN d∏ l√ ¥ (¿ ldescribes these r $‡ ° d ONLN d$∏ µ√ )Ioutines in detail. ° d ONLN d8 l’ (“ l"Drivers in the application heap ar Á‡ ° d ONLN dZ ’j )îe lost when the heap is r ∑ ° d ONLN ds k’› )k einitialized. If you set the . ° d ONLN dê’ l· ¥ (fi l dNeedGoodbye ° d ONLN dú÷ ¥· ª )H f PÄ ° d ONLN dû÷ ª·ò )/lag, the Device Manager calls your driver befor "‡ ° d ONLN dÕ÷ò·Ÿ )›e the heap is . ° d ONLN d€‚ lÌ o (Í lr E ° d ONLN d‹‚ pÌÅ )?einitialized so that you can perform any clean-up actions. See Y ° d ONLN d‚ÅÌê (ÍÅ“W õ¿ ° d ONLN d ‚èÌ” )riting the Contr D† ° d ONLN d-‚‘ÌÚ )Eol and ° d ONLN d4Ó l˘ û (ˆ l Status Subr ú ° d ONLN d?Ó û˘ Û )2outines” on page 2- ë ° d ONLN dRÓ Ù˘ ˛ )V15 ë ° d ONLN dTÓ ˛˘! )
for mor [† ° d ONLN d\Ó"˘K )$ e details. . ° d ONLN dh l s ( lY ï ° d ONLN di r ¢ ) ou set the ï ° d ONLN dtˇ ¢ ÿ )0 dNeedTime ï ° d ONLN d} ÿ ‚ )6 fl ï ° d ONLN dÄ ‚ )
ag of the ï ° d ONLN däˇ E )- drvrFlags ï ° d ONLN dì E Y )6 wor g` ° d ONLN dó Y Ì )!d if your device driver needs to . ° d ONLN d∏ l ˛ ( l perform some action periodically U ° d ONLN dÿ ˛Ê )í5. For example, a network driver may want to poll its ° d ONLN d
l# ï ( l input buf ∫` ° d ONLN d ï#. ))&fer every 5 seconds to see if it has r fi¿ ° d ONLN d<.#› )ô'eceived any messages. The value of the ˇˇ≤B . ° d ONLN dc# l/ ¢ (, l drvrDelay ˇˇŸ! ° d ONLN dl$ ¢/ µ )6 wor +Å ° d ONLN dp$ ∂/¯ )Ed indicates how many ticks should pass between periodic actions. For ˇ˛r⁄ ° d ONLN dµ0 l; Á (8 l example, a value of 0 in the ˇ¸Â¥ £ˆ ° d ONLN d“/ Á; ){ drvrDelay ˇ˛r⁄ £ˆ ° d ONLN d€0 ;/ )6 wor È0 ° d ONLN dfl0/;˜ )-d indicates that the action should happen as . ° d ONLN d < lGÛ (D l[often as possible, a value of 1 means it should happen every sixtieth of a second, a value ° d ONLN dgH lS * Wof 2 means at most every thirtieth of a second, and so on. Whether the action actually ° d ONLN dæT l_ • * occurs this fr ^¿ ° d ONLN dÃT •_· )9Eequently depends on how often the application calls the Desk Manager ˇˇtP . ° d ONLN d ` lk v (h lpr R` ° d ONLN d ` vk ì )
ocedur $¿ ° d ONLN d ` ìk ö ) e ˇ˛Ë† ô ° d ONLN d _ ök ÷ )
SystemTask ˇˇtP ô ° d ONLN d %` ÷k Ì )<. See Å∞ ° d ONLN d +` Ók ˛ )“W ƒP ° d ONLN d -` ˝kD )riting the Contr P ° d ONLN d =`Ekó )Hol and Status Subr Ɔ ° d ONLN d O`ókÎ )Routines” on page 2- ê ° d ONLN d b`Ïkˆ )U15 ê ° d ONLN d d`ˆk¯ )
. ° d ONLN d el lw ç (t lfor mor Ä ° d ONLN d ll çw ≥ )!
° d ONLN d h ä s¶ * AIf you do not want your driver to depend on applications to call ,
Courier ˇ˝ˇ¸ . ° d ONLN d A s ä Δ *
SystemTask ˇ˛ˇ˛ ° d ONLN d K t Δ √ )<;, you can still perform actions periodically by installing . ° d ONLN d Ü Ä ä ã § ( à äa VBL @ ° d ONLN d ã Ä • ã ‚ ) task, a Deferr {¿ ° d ONLN d ö Ä ‚ ã ı )=ed T ‡ ° d ONLN d û Ä ı ãU )ask Manager task, a T ó† ° d ONLN d ≥ ÄT 㪠)_ime Manager task, or a ° d ONLN d å ä ó £ ( î äNotifi {‡ ° d ONLN d – å § ó& ) cation Manager task. For mor Ñ ° d ONLN d Ï å& óØ )Ç e information, see the chapters ° d ONLN d ò ä £ õ ( † äcorr ` ° d ONLN d ò ú £ ) esponding to these managers. ,
In particular ‰` ° d ONLN d£ ∂ ¿ ¡# )6, you need to set this fl 7@ ° d ONLN dº ∂$ ¡Ç )dag in these two cases:
° d ONLN d” ä — è ( – än
° d ONLN d’ » ñ ” ) If any part of your driver (` ° d ONLN dÔ » ”Ö )p ’s code can be called at interr ä` ° d ONLN d »Ö ”Ø )
upt time. ¿ ° d ONLN d »Ø ”’ )* At interr ‡† ° d ONLN d! »’ ” )&upt time, the ° d ONLN d/ ‘ ñ fl ( ‹ ñYheap may not be in a consistent state. If your driver is not locked, the system could be ° d ONLN dà ‡ ñ Î ª * in the pr fi@ ° d ONLN dë ‡ ª Î „ )%
ocess of r ñ ° d ONLN dõ ‡ ‰ ÎG ))elocating it in memory j† ° d ONLN d± ‡G ÎI )c.
° d ONLN d≥ Ù ä ˚ è ( ˙ än
° d ONLN dµ Ú ñ ˝ fi ) If your driver pr — ° d ONLN dΔ Ú fi ˝ )HDovides the Operating System with a pointer to any part of its code. ° d ONLN d
˛ ñ › ( ñJFor example, if your driver uses the Device Manager to call another driver ∫† ° d ONLN dT ˛› (› , you might ° d ONLN d`
ñ ü ( ñpr G ° d ONLN db
†õ )
7ovide the Device Manager with a pointer to completion r N‡ ° d ONLN dô
õ
)˚outine. If that completion ° d ONLN d¥ ñ! ô ( ñr E ° d ONLN dµ ö!¯ )Poutine is in your driver code, your driver code must be locked. Otherwise, that ° d ONLN d" ñ-ˆ (* ñOpointer might not be valid by the time the Device Manager calls the completion ° d ONLN dT. ñ9 ô * r E ° d ONLN dU. ö9 ∏ )outine. ° d ONLN d]@ äK ê (H äY @Ä ° d ONLN d^@ êK ∏ ) ou can cr 4 ° d ONLN dg@ ∏K` )(&eate your driver header in these ways:
° d ONLN déT ä[ è (Z än
° d ONLN dêR ñ] ú ) Y @Ä ° d ONLN dëR ú] ÿ )ou can use a r —Ä ° d ONLN düR ÿ] )<esour ¿ ° d ONLN d§R Ò]$ ) ce compiler _ ° d ONLN dØR#]9 )2. See ≤ ° d ONLN dµR9]] )“Resour ®` ° d ONLN dºR]]ü )$ces” on page 2- î‡ ° d ONLN dÀR†]™ )C38 î‡ ° d ONLN dÕR™]
)
for the Rez format of ° d ONLN d‰^ ñi » (f ñ the driver r {† ° d ONLN d^ »i ‡ )2esour √‡ ° d ONLN dı^ ‡i Î )ce.
° d ONLN d˘r äy è (x än
. ° d ONLN d˚p ñ{ ù ) Y ï ° d ONLN d¸p ú{ fl )ou can use the ï ° d ONLN d o fl{ Î )CDC ï ° d ONLN d
p Î{ ) instr Å ° d ONLN dp{] )uction, as shown in Å ° d ONLN d'p]{ç )Z Listing 2-2 Å ° d ONLN d2pç{˛ )0, to position the header . ° d ONLN dK| ñá ⁄ (Ñ ñinformation dir ÑÄ ° d ONLN dZ| ⁄áÇ )D%ectly in your assembly language code.
™ H≠ 4™ H≠ "™ Ha
ˇ·ˇ‚7^
° d ONLN dˇˇ (ß ä Listing 2-2 ° d ONLN dˇˇ )D Åê ° d ONLN dÅü –™c )"An assembly-language driver header
. ° d ONLN d§∑ ä√ ¥ (¿ äDHeader ° d ONLN d¨≈ ä— Æ *DFlags ° d ONLN d∏≈ ¿— ÿ )6DC.B ° d ONLN dæ≈ ‰— Í )$0 ° d ONLN d≈≈P—∂ )l ;set by DRVROpen ° d ONLN d›” ¿fl ÿ (‹ ¿DC.B ° d ONLN d„” ‰fl Í )$0 ° d ONLN dÍ”Pfl∂ )l ;set by DRVROpen ° d ONLN d¸· äÌ Æ (Í äDDelay ° d ONLN d· ¿Ì ÿ )6DC.W ° d ONLN d· ‰Ì Í )$0 ° d ONLN d·PÌt )l ;none ° d ONLN d Ô ä˚ Æ (¯ äDEMask ° d ONLN d(Ô ¿˚ ÿ )6DC.W ° d ONLN d.Ô ‰˚ Í )$0 ° d ONLN d5ÔP˚™ )l ;DA event mask ° d ONLN dE˝ ä ® ( äDMenu ° d ONLN dP˝ ¿ ÿ )6DC.W ° d ONLN dV˝ ‰ Í )$0 ° d ONLN d]˝P Ü )l ;no menu ° d ONLN dm ¿ ÿ ( ¿DC.W ° d ONLN ds ‰ )$DOpen ° d ONLN dy > )
- DHeader ° d ONLN dà P∞ )N ;offset to Open ° d ONLN dü ¿% ÿ (" ¿DC.W ° d ONLN d• ‰% )$DPrime ° d ONLN d¨%D )$
- DHeader ° d ONLN dªP%∂ )H ;offset to Prime ° d ONLN d”' ¿3 ÿ (0 ¿DC.W ° d ONLN dŸ' ‰3V )$DControl - DHeader ° d ONLN dÚ'V3¬ )r;offset to Control ° d ONLN d 5 ¿A ÿ (> ¿DC.W ° d ONLN d5 ‰A )$DStatus ° d ONLN d5AJ )*
- DHeader ° d ONLN d(5PAº )B ;offset to Status ° d ONLN dAC ¿O ÿ (L ¿DC.W ° d ONLN dGC ‰O )$DClose ° d ONLN dNCOD )$
- DHeader ° d ONLN d]CPO∂ )H ;offset to Close ° d ONLN dp_ äk ¢ (h äName ° d ONLN dz_ ¿k ÿ )6DC.B ° d ONLN dÄ_ ‰k )$ '.DRIVER' ° d ONLN dè_Pk∞ )l ;name of driver ° d ONLN d¶m ¿y fi (v ¿ALIGN ° d ONLN d≠m ‰y Í )$2 ° d ONLN d¥mPyò )l ;word align ˇˇ¯å ° d ONLN d¡Ü äë Î (é äIn this example, the ˇˇÒ b0 ° d ONLN d÷Ö Ïë" )b drvrFlags ˇˇ¯å b0 ° d ONLN dflÜ"ë5 )6 wor - ° d ONLN d„Ü6ë` )
d is clear î ° d ONLN dÌÜ`ë¬ )*ed to 0—the actual fl “ƒ ° d ONLN dÜ√ëfi )cags ar ù∞ ° d ONLN dÜflë )
° d ONLN d ] l h ( e lsubr ¿ ° d ONLN d ] Ä h ∂ ) outines, defi Ç@ ° d ONLN d ] ∂ h )6ned in the next section, æ† ° d ONLN d * ] hæ )h!“Responding to the Device Manager ⁄ ° d ONLN d K ]æ h≈ )†.” Z ° d ONLN d M ]Δ h€ ) The ° d ONLN d R i l t) ( q l(header ends with the driver name and wor fi ° d ONLN d z i) t` )Ω d alignment.
ô * ü¯ 4 ö * ü¯ ö l ö¯
ˇ·ˇ‚7^
ˇˇ◊ ˇ◊ ° d ONLN d á â l ô` ( ï l Responding to the Device Manager ˇˇˇˇˇˇ • ( ï2
° d ONLN d ® † l ´ ( ® l&The Device Manager calls a driver subr Ö ° d ONLN d Œ † ´x )≠outine by setting up r Ä¿ ° d ONLN d ‰ †x ´Û )_ egisters and jumping to the ° d ONLN d ¨ l ∑ Å ( ¥ laddr |Ä ° d ONLN d ¨ Å ∑ Ó )ess indicated by the subr ö‡ ° d ONLN d ¨ Ó ∑ )m outine’s of ˝@ ° d ONLN d( ¨ ∑Ü ).fset in the driver header @ ° d ONLN dA ¨Ü ∑ã )j. ,
Zapf Dingbats
° d ONLN dD ¿ l « q ( Δ ln
° d ONLN dG æ x … û ) Register Ã` ° d ONLN dP æ û …g )&.A0 contains a pointer to the parameter block.
° d ONLN d “ l Ÿ q ( ÿ ln
° d ONLN dÇ – x € û ) Register Ã` ° d ONLN dã – û €P )&)A1 contains a pointer to the device contr 5Ä ° d ONLN d¥ –Q €s )≥ol entry V¿ ° d ONLN dº –r €t )!. ° d ONLN dæ ‚ l Ì Æ ( Í lThis interface r ¢† ° d ONLN dŒ ‚ Æ Ì ≈ )Bequir π‡ ° d ONLN d” ‚ ≈ Ì“ ):es you to use some assembly language when writing a driver æ ° d ONLN d
‚“ Ì◊ ( Í“. ° d ONLN d Ó l ˘ ï ( ˆ lHowever † ° d ONLN d Ó ï ˘" )) , you can write your driver subr ` ° d ONLN d6 Ó" ˘ÿ )ç*outines in a high-level language if you pr È¿ ° d ONLN d` Ó◊ ˘Ú )µovide ° d ONLN df ˙ l› ( lQan assembly-language dispatching mechanism that acts as an interface between the ° d ONLN d∑ l * #Device Manager and your driver subr ∂‡ ° d ONLN d⁄5 )ßoutines. ° d ONLN d„ l#5 ( l,The next few sections discuss how you can pr ¿† ° d ONLN d5#í )…ovide a dispatching r ˇ@ ° d ONLN d$í#Ì )]outine and how you ° d ONLN d7$ l/ ˘ (, l can implement your driver subr À‡ ° d ONLN dU$ ˘/à )ç!outines in a high-level language.
M *T¯ 4N *T¯ O lO¯
ˇ·ˇ‚7^
° d ONLN dw@ lM Ë (J lEntering and Exiting Fr Í@ ° d ONLN dé@ ËM: )|om Driver Subr Ü¿ ° d ONLN dú@;Ma )Soutines ˇˇˇˇˇˇ )∑2
° d ONLN d§U l` ö (] l Listing 2-3 @ ° d ONLN dØU õ`$ )/ shows an assembly-language r ·‡ ° d ONLN dÃU$`Î )â-outine that you can use an interface between ° d ONLN d˘a ll} (i l;the Device Manager and your high-level language driver subr 5` ° d ONLN d4a~lÏ (i~outines. In this example, ° d ONLN dNm lx ¥ (u leach driver subr u@ ° d ONLN d^m ¥x£ )H5outine (which the Device Manager locates using the of 9‡ ° d ONLN dìm§xÀ ) fsets defi Ö‡ ° d ONLN dùmÀxÈ )'ned in ° d ONLN d§y lÑ ö (Å l Listing 2-2 @ ° d ONLN dØy õÑ Á )/) pushes the addr Ï@ ° d ONLN d¿y ÁÑ )Less of its corr ~` ° d ONLN dœy!Ñ¿ ):"esponding high-level language subr dÄ ° d ONLN dÒy¿ÑÚ )ü outine and ° d ONLN d¸Ö lê ˘ (ç l then branch to the dispatching r ¶` ° d ONLN d Ö ˘ê )çoutine.
≤ *∂¯ 4≥ *µ¯ "≥ *a
ˇ·ˇ‚7^
° d ONLN dˇˇ (∞ l Listing 2-3 ° d ONLN d$® ∞≥^ )D,Entering and exiting from driver subroutines ,
Courier
. ° d ONLN dQø lÀ ä (» lDOpen ° d ONLN d\ø ¢À ¥ )6pea ° d ONLN daø ΔÀ ˆ )$DRVROPEN ° d ONLN dpÕ ¢Ÿ ¿ (÷ ¢bra.s ° d ONLN dwÕ ΔŸ )$ DRVRDispatch ° d ONLN dâÕ2Ÿ8 )l ° d ONLN dêÈ lı ê (Ú lDPrime ° d ONLN dúÈ ¢ı ¥ )6pea ° d ONLN d°È Δı ¸ )$ DRVRPRIME ° d ONLN d±˜ ¢ ¿ ( ¢bra.s ° d ONLN d∏˜ Δ )$ DRVRDispatch ° d ONLN d l ú ( lDControl ° d ONLN dÿ ¢ ¥ )6pea ° d ONLN d› Δ )$ DRVRCONTROL ° d ONLN dÔ! ¢- ¿ (* ¢bra.s ° d ONLN dˆ! Δ- )$ DRVRDispatch ° d ONLN d
= lI ñ (F lDStatus ° d ONLN d= ¢I ¥ )6pea ° d ONLN d = ΔI )$
DRVRSTATUS ° d ONLN d-K ¢W ¿ (T ¢bra.s ° d ONLN d4K ΔW )$ DRVRDispatch ° d ONLN dBg ls ê (p lDClose ° d ONLN dNg ¢s ¥ )6pea ° d ONLN dSg Δs ¸ )$ DRVRCLOSE ° d ONLN dbg2sÏ )l ;and fall thru to DRVRDispatch ˇ > @ ˇ ˇˇˇˇ @
) ;restore registers (for IODone) ° d ONLN d· ⁄ ¿ Ê ‰ ( „ ¿addq.w ° d ONLN dÍ ⁄ ˆ Ê )6#4, a7 ° d ONLN dÙ ⁄> ÊD )H ° d ONLN dˆ ⁄P Ê ) ;clear subroutine addr off stack ° d ONLN d ˆ ¿ fi ( ˇ ¿cmp.w ° d ONLN d& ˆ ˆ )6#1, d0 ° d ONLN d1 ˆP¯ )Z ;if incomplete async routine ° d ONLN dT ¿ fi (
¿beq.s ° d ONLN d\ ˆ )6Done ° d ONLN dd>D )H ° d ONLN dfP ) ;then rts -- don't jmp to IODone ° d ONLN dé ¿, ÿ () ¿btst ° d ONLN dï ˆ,, )6 #1,$6(a0) ° d ONLN d£ P,¬ )Z;test immediate bit ° d ONLN dΩ. ¿: fi (7 ¿bne.s ° d ONLN d≈. ˆ: )6Done ° d ONLN dŒ.P:Œ )Z;rts if immed bit set ° d ONLN dÍ< ¿H ‰ (E ¿move.l ° d ONLN dÛ< ˆHJ )6JIODone, -(sp) ° d ONLN d<PH
)Z ;push JIODone vector onto stack ° d ONLN d'X äd ¢ (a äDone ° d ONLN d1X ¿d “ )6rts ˇˇóB ° d ONLN d5q ä| û (y äThe ˇˇ.Ñ B ° d ONLN d9p ü| Á ) DRVRDispatch ˇˇóB B ° d ONLN dEq Á| Ì )H r ĉ ° d ONLN dGq Ì|j ) outine begins by saving the Œ ° d ONLN dcqk|é )~A0 and ÊÚ ° d ONLN djqç|† )"A1 r Pî ° d ONLN dnq°|ı )egisters, clearing r Qx ° d ONLN dÇqı| )Toom on . ° d ONLN dâ} äà ÷ (Ö äthe stack for the r :Ä ° d ONLN dú} ◊à )MGesult code, and pushing the parameters on the stack and jumping to the ° d ONLN d„â äî û (ë äappr I@ ° d ONLN dÁâ üî Ú )opriate driver subr ë‡ ° d ONLN d˙â Úî )Soutine. ˇˇœ4 . ° d ONLN dõ ä¶ Ì (£ äWhen the driver subr ø¸ ° d ONLN dõ ̶ )coutine r aê ° d ONLN d õ¶C )# eturns, the ˇˇûh ˇ¯ ° d ONLN d+öC¶ã )3 DRVRDispatch ˇˇœ4 ˇ¯ ° d ONLN d7õã¶ë )H r °å ° d ONLN d9õí¶Ê )outine moves the r ·à ° d ONLN dKõʶ )T esult code . ° d ONLN dVß ä≤ ô (Ø äto r |‡ ° d ONLN dZß ô≤ Œ )
egister D0, r ˚‡ ° d ONLN dgß Œ≤ „ )5estor ` ° d ONLN dlß ‰≤ ˇ )es the ° d ONLN dsß ≤" ) A0 and [ ° d ONLN dzß"≤5 )"A1 r g@ ° d ONLN d~ß5≤õ )egisters, clears the subr · ° d ONLN dóßõ≤Œ )f outine addr ü‡ ° d ONLN d¢ßœ≤Ê )4ess fr |` ° d ONLN d®ßÊ≤ )om the ° d ONLN dØ≥ äæ ” (ª ästack, and then r _† ° d ONLN d¿≥ ”æ )I eturns contr ≤@ ° d ONLN dÃ≥æœ )5,ol to the Device Manager in one of two ways: ,
Zapf Dingbats
° d ONLN d˘« äŒ è (Õ än
. ° d ONLN d˚≈ ñ– ° ) W Û` ° d ONLN d¸≈ †– ¿ )
ith an Û` ° d ONLN dƒ ¿– “ ) RTS Û` ° d ONLN d≈ “– Í ) instr fl` ° d ONLN d ≈ Í– )uction. ±¿ ° d ONLN d≈ – )!Y Δ¿ ° d ONLN d≈–» )&ou do not want the Device Manager to r ô ° d ONLN d;≈»– )∑
emove to the ° d ONLN dH— ñ‹ ö (Ÿ ñr R` ° d ONLN dI— ö‹ ¡ ) equest fr $¿ ° d ONLN dR— ¡‹ )'om the driver r ˜ ° d ONLN da—‹Ä )Fequest queue. In particular 9¿ ° d ONLN d|—Ä‹ô )y, the 9¿ ° d ONLN dÇ–ô‹· ) DRVRDispatch 9¿ ° d ONLN dé—·‹Ë )H r ° d ONLN dê—Ë‹ )outine ˇˇ
° d ONLN dó› ñË ö ( ñr R` ° d ONLN dò› öË › )eturns with an ˇ˛$ yñ ° d ONLN dß‹ ›Ë Ô )CRTS ˇˇ
yñ ° d ONLN d™› ÔË ) instr r® ° d ONLN d∞›Ë+ ) uction fr R ° d ONLN dπ›+Ër )%om immediate r >û ° d ONLN d«›rË )G"equests (which the Device Manager . ° d ONLN dÈÈ ñÙ (Ò ñ never adds to the queue) and fr ¿ ° d ONLN dÈ!Ùi )ãom incomplete r ]‡ ° d ONLN dÈiÙ )H%equests that the driver is executing ° d ONLN d<ı ñ ∏ (˝ ñasynchr $ ° d ONLN dCı π % )#onously (which should r Ä ° d ONLN dZı% )l5emain in the queue until the driver completes them). ° d ONLN dè ñ ⁄ ( ñThe driver subr %¿ ° d ONLN dû € )E outines r Í ° d ONLN dß & )& eturn a r Ü@ ° d ONLN d∞' ¡ )&&esult code of 1 to indicate that the r =¿ ° d ONLN d÷¬ ˝ )õequest is still ° d ONLN dÊ
ñ … ( ñ incomplete.
° d ONLN dÚ! ä( è (' än
. ° d ONLN dÙ ñ* Î ) By jumping to the ° d ONLN d Î* )UIODone ° d ONLN d * )$ r R` ° d ONLN d *T )outine. This r $¿ ° d ONLN d T*› )> outine, described in detail on $¿ ° d ONLN d; ›*˛ )âpage 2- $¿ ° d ONLN dB ˛* )!38 $¿ ° d ONLN dD * )
, . ° d ONLN dF+ ñ6N (3 ñ*indicates to the Device Manager that the r Ê@ ° d ONLN dp+N6 )∏'equest is complete. The Device Manager ˇˇ¯U ° d ONLN dó7 ñB ≠ (? ñwill r Õu ° d ONLN dù7 ≠B · ) emove the r „ ° d ONLN d®7 ·B )4 equest fr 'î ° d ONLN d±7BJ )'om the driver r ’≥ ° d ONLN d¿7JBÙ )B&equest queue and call the completion r E1 ° d ONLN dÊ7ıB )´outine. ° d ONLN dÔI äTí (Q ä;The next few sections discuss how to write your driver subr ä` ° d ONLN d*IíT¥ (Qíoutines.
r Hy 4s Hy t ät
ˇ·ˇ‚7^
° d ONLN d3e är ñ (o äW ú¿ ° d ONLN d4e ïr9 ) riting the Open and Close Subr G@ ° d ONLN dRe:r` )•outines ˇˇˇˇˇˇ )÷2
our Open r Ì¿ ° d ONLN d 7§ ¿Ø¿ )0;outine must allocate any private storage that your driver r p ° d ONLN d r§¡Øÿ (¨¡equir á@ ° d ONLN d w§ÿØ ) es and stor 4‡ ° d ONLN d Ç§Ø )0e . ° d ONLN d Ñ∞ äª (∏ ä a handle to this storage in the ° d ONLN d §Ø ª^ )í dCtlStorage ° d ONLN d Ø∞^ªh )B fi ° d ONLN d ≤∞hª– )
eld of the device contr R` ° d ONLN d …∞–ªÙ )hol entry 6† ° d ONLN d —∞Ûª˘ )#. ˇfi @ ˇ ˇˇˇˇ @
° d ONLN d ] l h¿ ( e lPAfter allocating private storage, you should initialize it and do any further pr † ° d ONLN d P ]¡ hÌ ( e¡
eparation ° d ONLN d Z i l t o ( q lr E ° d ONLN d [ i p t á )equir \@ ° d ONLN d ` i á t ‘ )ed by your driver r† ° d ONLN d q i ‘ t ÷ )M. ° d ONLN d s { l Ü r ( É lY @Ä ° d ONLN d t { r Ü Á ) ou might also install interr X ° d ONLN d ê { Á Ü_ )uupt handlers, change interr F† ° d ONLN d ´ {_ Üπ )xupt vectors, and stor ‡ ° d ONLN d ¿ {∫ ܈ )[e a pointer to ° d ONLN d œ á l í ≤ ( è lthe device contr …¿ ° d ONLN d fl á ≤ í )Fol entry somewher ç‡ ° d ONLN d á íâ )S!e in local storage for the interr 8` ° d ONLN d áä í˜ )Öupt handlers to use. The ° d ONLN d* ì l û ç ( õ lsection ËÄ ° d ONLN d2 ì ç û “ )!“Handling I/O CÄ ° d ONLN d@ ì ” û ¯ )FAsynchr Ƈ ° d ONLN dG ì ¯ ûP )%onously” on page 2- úÄ ° d ONLN dZ ìQ û[ )Y17 úÄ ° d ONLN d\ ì[ û° )
discusses interr l† ° d ONLN dm ì¢ ûÈ )Gupt handling in ° d ONLN d} ü l ™ ~ ( ß lmor éÄ ° d ONLN dÄ ü ~ ™ † ) e detail. ° d ONLN dä ± l º ¬ ( π lThe DrvrDispatch r ≤@ ° d ONLN dú ± ¬ º Î )V
outine in Æ` ° d ONLN d¶ ± Ï º )* Listing 2-3 N† ° d ONLN d± ± º! )/ r ì† ° d ONLN d≥ ±! ºS ) eturns the r J ° d ONLN dø ±T º‘ )3 esult codes of the driver subr õÄ ° d ONLN d› ±‘ ºˆ )Äoutines ° d ONLN dÂ Ω l » { ( ≈ lin r ~¿ ° d ONLN dÈ Ω { » ÷ )egister D0. However ≈` ° d ONLN d¸ Ω ’ » ˜ )Z, upon r ZÄ ° d ONLN d Ω ¯ » )#eturn fr Ä ° d ONLN d Ω »h )!om the Open subr { ° d ONLN d Ωi »Â )Poutine, the Device Manager ° d ONLN d7 … l ‘ Ç ( — lsets r K ° d ONLN d= … É ‘ Ÿ )egister D0 to 0; ther _@ ° d ONLN dR … Ÿ ‘ Í )Vefor ∑@ ° d ONLN dV … Í ‘* )e, your Open r Ω@ ° d ONLN dd …* ‘ó )@outine should place the r UÄ ° d ONLN d} …ò ‘‚ )nesult code in the ,
Courier . ° d ONLN dè ‘ l ‡ ú ( › lioResult ° d ONLN dó ’ ú ‡ £ )0 f PÄ ° d ONLN dô ’ £ ‡) ) ield of the parameter block. ˇˇÉÀ ° d ONLN d∑ Á l Ú õ ( Ô l Listing 2-4 À ° d ONLN d¬ Á ú Ú )0 shows a sample Open subr i" ° d ONLN d€ Á Ú6 )youtine, ˇˇñ ÏÌ ° d ONLN d„ Ê6 Úf )!DRVROpen ˇˇÉÀ ÏÌ ° d ONLN dÎ Áf ÚÄ )0. The ˇˇñ ÙÉ ° d ONLN dÒ ÊÄ Ú∞ )DRVROpen ˇˇÉÀ ÙÉ ° d ONLN d˘ Á∞ Ú˜ )0 function begins . ° d ONLN d
Û l ˛ ∞ ( ˚ lby setting the fl ’ ° d ONLN d Û ∞ ˛ )Dags of the device contr ¥` ° d ONLN d2 Û ˛K )col entry (see Ä ° d ONLN d@ ÛL ˛´ )9Listing 2-2 on page 2- +` ° d ONLN dV Û´ ˛∞ )_9 +` ° d ONLN dW Û∞ ˛Û )) and checking ˇ˛Ld . ° d ONLN df ˇ l
‹ ( lwhether the driver is alr É ° d ONLN d ˇ ‹
ù )p,eady open (by examining the contents of the ˇ¸ò» Á ° d ONLN d´ ˛ù
fl )¡ dCtlStorage ˇ˛Ld Á ° d ONLN d∂ ˇfl
Á )B fi 3t ° d ONLN dπ ˇË
¯ ) eld ˇˇ„Ú ° d ONLN dΩ l ¡ ( lof the device contr ˛6 ° d ONLN d– ¡V )U#ol entry). If the driver is not alr 4 ° d ONLN dÛ Wû )ñeady open, the ˇˇ«‰ ∏
° d ONLN d
ûŒ )GDRVROpen ˇˇ„Ú ∏
° d ONLN d
Œ˜ )0
function . ° d ONLN d l"Í ( lXallocates memory for private storage. The private storage of the driver in this example ˇ˛≠¥ . ° d ONLN dl# l. ¨ * contains two fi €h ° d ONLN d{# ¨. ’ )@
, and the ˇ˝[h “8 ° d ONLN dº"“.ˆ ))buffer ˇ˛≠¥ “8 ° d ONLN d¬#ˆ.˜ )$ . ° d ONLN d√/ l: r (7 lfi å¿ ° d ONLN d≈/ r: ì )eld stor î` ° d ONLN dÕ/ ì: ¥ )!es a buf P ° d ONLN d’/ µ:I )""fer of 255 bytes. The Prime, Contr ,Ä ° d ONLN d˜/I:õ )îol, and Status subr ‡ ° d ONLN d
/õ:ˆ )Routines described in ° d ONLN d ; lF ¸ (C l!the next two sections use these fi ñ@ ° d ONLN dA; ¸F )êelds. ˇ˛æƒ . ° d ONLN dGM lX á (U lIf the ˇ˝}à ˝à ° d ONLN dNL áX ∑ )DRVROpen ˇ˛æƒ ˝à ° d ONLN dVM ∑Xµ )0< function fails to allocate memory for private storage, it r Cê ° d ONLN díM∂X¯ )ˇeturns with an ˇˇØ ° d ONLN d°Y ld ï (a l openErr r u ° d ONLN d™Y ñd › )*esult code. The ˇˇ^* ¥ ° d ONLN d∫X ›d% )G DRVRDispatch ˇˇØ ¥ ° d ONLN dΔY%d+ )H r ê) ° d ONLN d»Y+dM )outine r û ° d ONLN d–YNdÖ )#
eld of . ° d ONLN d•} là Δ (Ö lthe parameter block.
™ *Ư 4´ *≠¯ "´ *a
ˇ·ˇ‚7^
° d ONLN dˇˇ *# Listing 2-4 ° d ONLN d∫† ∞´, )D Sample Open driver subroutine
. ° d ONLN dÿ∑ l√ Ñ (¿ lTYPE ° d ONLN d·≈ ~— +MyDriverGlobals = RECORD ° d ONLN dˇ” êfl ¿ +numBeeps ° d ONLN d” ¿fl ¸ )0
: LongInt; ° d ONLN d· êÌ ¥ (Í êbuffer ° d ONLN d · ¥Ì Í )$ : Str255; ° d ONLN d.Ô ~˚ ñ (¯ ~END; ° d ONLN d7˝ ~ Í *MyDriverGlobalsPtr ° d ONLN dJ˝ Í \ )l= ^MyDriverGlobals; ° d ONLN db ~ Í ( ~MyDriverGlobalsHdl ° d ONLN du Ín )l= ^MyDriverGlobalsPtr; ° d ONLN dç' l3h (0 l*FUNCTION DRVROpen (VAR pb: ParamBlockRec; ° d ONLN d¡5 ÿAÄ +l VAR dce: DCtlEntry): OSErr; ° d ONLN dflQ l] ä (Z lBEGIN ° d ONLN dÈ_ ~k Í +DRVROpen := NoErr; ° d ONLN d m ~yÊ *<dce.dCtlFlags := BOr(dCtlEnable + dStatEnable + dWritEnable ° d ONLN dH{ ¸áÊ +~'+ dReadEnable + dNeedLock + dRAMBased, ° d ONLN d{â ¸ïV *dce.dCtlFlags); ° d ONLN dï• ~±> (Æ ~ IF (dce.dCtlStorage <> NIL) THEN ° d ONLN dª≥ êø Æ +BEGIN ˇ. @ ˇ ˇˇˇˇ @
. ° d ONLN d \ ¿ hP ( e ¿{driver is already open} ° d ONLN d j Æ v ¿ ( s ÆEND ° d ONLN d & x ú Ñ ¥ ( Å úELSE ° d ONLN d 8 Ü Æ íí +&BEGIN {need to initialize dCtlStorage} ° d ONLN d e î ¿ †¯ +4dce.dCtlStorage := NewHandle(sizeof(MyDrvrGlobals)); ° d ONLN d † ¢ ¿ Æz * IF (dce.dCtlStorage = NIL) THEN ° d ONLN d « ∞ “ ºD +DRVROpen := openErr ° d ONLN d · æ ¿ ÿ ( « ¿ELSE ° d ONLN d Ì Ã “ ÿP +pb.ioResult := noErr; ° d ONLN d ⁄ Æ Ê Δ ( „ ÆEND; ° d ONLN d
Ë ä Ù ¢ ( Ò äEND; . ° d ONLN d ä ê *Y @Ä ° d ONLN d ê – )our Close subr º ° d ONLN d! – )@
outine must r ‡ ° d ONLN d. C )<
everse the ef ‡ ° d ONLN d;C ´ )7fects of your Open subr ¸Ä ° d ONLN dR™ ⁄ )g outine by r † ° d ONLN d]€ )1
)ime Manager tasks, ° d ONLN dº ä$ ° (! äand r ≤ ° d ONLN d¡ °$ )eplacing changed interr =‡ ° d ONLN dÿ
$@ )i
upt vectors. ° d ONLN dÊ+ ä6 (3 äXIf you want to save any information about the operational state of the driver until the ° d ONLN d>7 äBY * /next time the driver is opened, you should stor w ° d ONLN dm7YB¿ )œe this information in a r 4 ° d ONLN dÜ7¡B )helocatable block of . ° d ONLN döC äN (K ämemory pointed to by the ° d ONLN d≥BNF )z dCtlStorage ° d ONLN dæCFNP )B fi ° d ONLN d¡CPN )
)eld, because the Device Manager does not . ° d ONLN dÍO äZ (W ädispose of the device contr RÄ ° d ONLN dO Zç )v!ol entry when a driver is closed. ˇˇnw . ° d ONLN d'a äl π (i ä Listing 2-5 Ów ° d ONLN d2a πl3 )/ shows a sample Close subr È* ° d ONLN dLa3lT )zoutine, ˇ˛‹Ó W° ° d ONLN dT`Ulã )" DRVRClose ˇˇnw W° ° d ONLN d]aãlΩ )6 . Since the ˇ˛‹Ó £ ° d ONLN di`ΩlÌ )2DRVROpen ˇˇnw £ ° d ONLN dqaÌl )0
function . ° d ONLN d{m äxˆ (u äUfor this sample driver allocated private storage, and the driver doesn’t need to stor ° d ONLN d–mˆx (uˆe any ˇˇU . ° d ONLN d÷y äÑ] (Å ä0information until the next time its opened, the ˇ˛*™ *® ° d ONLN dx^Ñî )‘ DRVRClose ˇˇU *® ° d ONLN dyîÑ )6 function simply disposes the . ° d ONLN d-Ö äê Œ (ç äprivate storage.
≤ H∂ 4≥ Hµ "≥ Ha
ˇ·ˇ‚7^
° d ONLN dˇˇ *# Listing 2-5 ° d ONLN d>® Œ≥K )D Sample Close driver subroutine
. ° d ONLN d]ø äÀå (» ä+FUNCTION DRVRClose (VAR pb: ParamBlockRec; ° d ONLN díÕ ˆŸ§ +l VAR dce: DCtlEntry): OSErr; ° d ONLN dµÈ úı ∫ (Ú úBEGIN ° d ONLN d¿˜ Æn + IF (dce.dCtlStorage <> nil) THEN ° d ONLN dÁ ¿ fi +BEGIN ° d ONLN dÙ “ Ü + DisposHandle(dce.dCtlStorage); ° d ONLN d! “-\ *dce.dCtlStorage := nil; ° d ONLN d8/ ¿; ÿ (8 ¿END; ° d ONLN dCK ÆW (T ÆDRVRClose := NOErr; ° d ONLN d[Y úe ¥ (b úEND;
Ü Hç 4Ü Hå á äá
ˇ·ˇ‚7^
. ° d ONLN d`x äÖ ñ (Ç äW ú¿ ° d ONLN dax ïÖ ) riting the Prime Subr ° d ONLN dvxÖ& )poutine ˇˇˇˇˇˇ (Ç2
° d ONLN d}ç äò ê (ï äY @Ä ° d ONLN d~ç êò ¬ ) our Prime r ˜ ° d ONLN dâç ¬ò? )2outine implements the I/O r Ñ@ ° d ONLN d§ç@òe )~ equests. FÄ ° d ONLN d≠çfòl )&Y ° d ONLN dÆçlòÌ ) ou can write your Prime subr î† ° d ONLN d çÌò )Åoutine ° d ONLN d—ô ä§ ÷ (° äto execute synchr @ ° d ONLN d‚ô ◊§+ )Monously or asynchr üÄ ° d ONLN dÙô+§N )Tonously ˚¿ ° d ONLN d˚ôM§R )". ù` ° d ONLN d˝ôR§Y )A ÿ ° d ONLN d˛ôY§y ) synchr ¸ ° d ONLN dôy§« ) onous Prime subr † ° d ONLN dô»§Ê )Ooutine ° d ONLN d • ä∞ € (≠ äcompletes an entir ì ° d ONLN d.• €∞ ˙ )Qe I/O r k@ ° d ONLN d5• ˙∞0 ) equest befor }¿ ° d ONLN dA•0∞; )6e r å` ° d ONLN dD•;∞« ) eturning to the Device Manager e† ° d ONLN db•«∞à )å. @ ° d ONLN dd•Ã∞‹ )An ° d ONLN dg± äº ¨ (π äasynchr $ ° d ONLN dn± ≠º ˚ )#onous Prime subr 7† ° d ONLN d~± ˚º∞ )N)outine can begin an I/O transaction but r ¨ ° d ONLN dß±∞º )µeturn to the Device ˇ é @ ˇ ˇˇˇˇ @
] ≠ h » )Ae the r ›† ° d ONLN d ] » h| )+equest is complete. In this case, the I/O r ˚† ° d ONLN d ? ]| h‡ )¥equest continues to be ° d ONLN d V i l t Ó ( q l executed, typically when mor 9 ° d ONLN d r i Ô tm )É e data is available, by other r ÿ ° d ONLN d ë im tÀ )~outines such as interr 1 ° d ONLN d ß ià t› )_upt ° d ONLN d ´ u l Ä Ÿ ( } lhandlers or completion r ¨¿ ° d ONLN d √ u Ÿ Ä3 )moutines. The section –` ° d ONLN d ÿ u3 Äx )Z“Handling I/O +` ° d ONLN d Ê uy Äû )FAsynchr ñ¿ ° d ONLN d Ì uû ÄÓ )%onously” on page ° d ONLN d ˛ Å l å t ( â l2- ”‡ ° d ONLN d Å t å ~ )17 ”‡ ° d ONLN d Å ~ å( )
% discusses how to complete an asynchr R ° d ONLN d' Å) åw )´onous Prime subr e† ° d ONLN d7 Åw åï )Noutine.
ô * ¶¯ 4 ö * •¯
° d ONLN dˇˇ ( ° lNOTE
ˇ·ˇ‚7^
° d ONLN d? § l Ø ® * Notice the dif ∞¿ ° d ONLN dM § ® Ø ¥ )<fer ì@ ° d ONLN dP § ¥ Ø ) ence between asynchr [Ä ° d ONLN dd § Ø6 )aonous r ° ° d ONLN dk §6 Øl )! equests and ° d ONLN dw ∞ l ª é ( ∏ lasynchr $ ° d ONLN d~ ∞ è ª ¿ )#
onous subr 5` ° d ONLN dà ∞ ¿ ªÑ )1*outines. The Device Manager places asynchr W` ° d ONLN d≤ ∞Ñ ª° )ƒonous ° d ONLN d∏ º l « o ( ƒ lr E ° d ONLN dπ º p « ≤ )equests in the r ° d ONLN d… º ≥ « )Cequest queue and r 0† ° d ONLN d€ º «< )T eturns contr É@ ° d ONLN dÁ º< «ñ )5ol to the application ° d ONLN d˝ » l ” õ ( – l
right away H@ ° d ONLN d » õ ” † )/. ȇ ° d ONLN d » ü ” ƒ )Asynchr U@ ° d ONLN d » ≈ ” ˆ )&
onous subr fÄ ° d ONLN d » ˆ ”! )1
outines ar *‡ ° d ONLN d$ »" ”ç ),e capable of satisfying a ° d ONLN d> ‘ l fl w ( ‹ llar -` ° d ONLN dA ‘ x fl à ) ge r À ° d ONLN dE ‘ à flA ),equest in small pieces, one piece at a time. ,
Zapf Dingbats
M¿ ° d ONLN dˇˇ )Ωu
° d ONLN dÜ Ê l Ò1 ( Ó l,The Device Manager indicates whether it is r Î` ° d ONLN d≤ Ê1 Òú )≈equesting a Read or a W •@ ° d ONLN d… Êú ÒË )krite operation by ˇˇÇÿ . ° d ONLN d€ Ú l ˝U ( ˙ l4placing one of the following constants in the low-or i ° d ONLN d ÚU ˝õ )Èder byte of the ,
G4 )6outines— ˇ˝` È0 ° d ONLN d“;4GR )*Fetch ˇ˛ç∞ È0 ° d ONLN d◊<RGf ) and ˇ˝` ê ° d ONLN d‹;gGÖ )Stash ˇ˛ç∞ ê ° d ONLN d·<ÖGØ ) —that pr d† ° d ONLN dÈ<ØG¯ )*ovide low-level . ° d ONLN d˘H lS § (P l
support for r Û‡ ° d ONLN dH §SP )8'eading and writing characters to and fr jÄ ° d ONLN d-HQSÜ )≠ om data buf « ° d ONLN d8HÜS” )5fers. Use of these ° d ONLN dKT l_ o (\ lr E ° d ONLN dLT p_ ˚ )!outines is optional. The section _† ° d ONLN dmT ˚_\ )ã“Routines” on page 2- † ° d ONLN dÇT]_g )b36 † ° d ONLN dÑTg_≤ )
ioActCount ˇˇ2 Ùæ ° d ONLN d€ri}r )< fi ° d ONLN dfirs}˙ )
eld of the parameter block. If . ° d ONLN d˝~ lâ Õ (Ü lyou do not use these r › ° d ONLN d~ Õâ )aoutines, you ar ≠ ° d ONLN d"~â )Be r ª¿ ° d ONLN d%~âû ) esponsible for updating this fi Ä ° d ONLN dD~üâ± )Öeld. ˇˇDD . ° d ONLN dJê lõw (ò l<If your driver serves a block device, you should update the ˇ˛àà nÏ ° d ONLN dÜèxõ¿ (òx dCtlPosition ˇˇDD nÏ ° d ONLN díê¿õ… )H fi ≥0 ° d ONLN dïê…õ˜ ) eld of the . ° d ONLN d†ú lß ¢ (§ l device contr l` ° d ONLN d¨ú ¢ß ƒ )6ol entry ç† ° d ONLN d¥ú √ß » )!. . ° d ONLN d∑Æ lπ ú (∂ l Listing 2-4 ° d ONLN d¬Æ úπ )0 shows a sample Prime subr R` ° d ONLN d‹Æπ= )outine, R` ° d ONLN d‰≠=πs )" DRVRPrime R` ° d ONLN dÌÆsπé )6. The R` ° d ONLN dÛ≠éπƒ ) DRVRPrime R` ° d ONLN d¸ÆƒπÓ )6
function . ° d ONLN d∫ l≈ “ (¬ lallows applications to r K ° d ONLN d ∫ ”≈◊ )g=ead and write up to 255 bytes of data to its private data buf Ê ° d ONLN d[∫◊≈„ (¬◊fer 8¿ ° d ONLN d^∫„≈Ë ) . ˇˇı . ° d ONLN daà l◊ Ä (‘ lThe ˇˇÍ u ° d ONLN deÀ Å◊ ∑ ) DRVRPrime ˇˇı u ° d ONLN dnà ∑◊ )6 function checks the r j ° d ONLN dÑÃ◊› )b-equested byte count and lowers it if it is gr ä‹ ° d ONLN d±Ã›◊˜ )ƒeater . ° d ONLN d∑ÿ l„ Ú (‡ l than the size of the private buf † ° d ONLN d◊ÿ Û„ ˇ )áfer o` ° d ONLN d⁄ÿ ˛„∞ ) (. Then, the function examines the low-or è` ° d ONLN dÿ∞„Ú )≤der byte of the . ° d ONLN d„ lÔ ê (Ï lioTrap ° d ONLN d‰ êÔ ó )$ f PÄ ° d ONLN d‰ óÔÓ )Gield of the parameter block to determine whether the Device Manager is . ° d ONLN da l˚ o (¯ lr E ° d ONLN db p˚ ® )
: Integer; ° d ONLN d ª π Æ ≈ fi ( ¬ ÆnumBytes ° d ONLN d ƒ π fi ≈ )0
: LongInt; ° d ONLN d ‘ ’ ú · ∫ ( fi úBEGIN ° d ONLN d fl „ Æ Ô +DRVRPrime := NoErr; ° d ONLN d ˙ ˇ Æ n * IF (dce.dCtlStorage <> nil) THEN ° d ONLN d!
¿ fi +BEGIN ° d ONLN d. “'Ê +.dStore := MyDriverGlobalsHdl(dce.dCtlStorage); ° d ONLN dd) “5n *numBytes := pb.ioReqCount; ° d ONLN dÜ7 “CV *IF numBytes > 256 THEN ° d ONLN d•E ‰QD +numBytes := 256; ° d ONLN dΩS “_û (\ “"callType := BAND($00FF,pb.ioTrap); ° d ONLN dÎo “{2 * CASE callType OF ° d ONLN d} ‰â∂ +#aRdCmd: BlockMove(@dStore^^.buffer, ° d ONLN d6ãPó‘ +lpb.ioBuffer,numBytes); ° d ONLN dUô ‰• (¢ ‰aWrCmd: ° d ONLN d]ô•ò )*BlockMove(pb.ioBuffer, ° d ONLN dÇß>≥Ï +0 @dStore^^.buffer,numBytes); ° d ONLN dßµ “¡ Í (æ “END; ° d ONLN d≥√ “œn *pb.ioActCount := numBytes; ° d ONLN d‘— ¿› “ (⁄ ¿END ° d ONLN d›fl ÆÎ Δ (Ë ÆELSE ° d ONLN dËÌ ¿˘> +DRVRPrime := mFulErr; ° d ONLN d˚ ú ¥ ( úEND;
( H/ 4( H. ) ä)
ˇ·ˇ‚7^
. ° d ONLN d ä' ñ ($ äW ú¿ ° d ONLN d ï' Á ) riting the Contr ° d ONLN d Ë'H )Sol and Status Subr |¿ ° d ONLN d*H'n )`outines ˇˇˇˇˇˇ )»2
° d ONLN d2/ ä: ‡ (7 äLike the Prime subr M@ ° d ONLN dE/ ·:, )Woutine, the Contr R@ ° d ONLN dV/,:{ )Kol and Status subr ∂† ° d ONLN dh/{: )O#outines that you write can execute ° d ONLN dã; äF ß (C äsynchr $ ° d ONLN dë; ®F ¸ ) onously or asynchr ®` ° d ONLN d£; ¸F )Tonously † ° d ONLN d™; F$ )#. . ° d ONLN d≠M äX~ (U ä2The Device Manager passes information to the Contr R` ° d ONLN dflM~Xé )Ùol r $¿ ° d ONLN d„MéXà )outine in the $¿ ° d ONLN dÒLÃX )>csCode $¿ ° d ONLN d˜MX )$ and ˇ˛—∫ ° d ONLN d¸X äd ¥ (a äcsParam ˇˇh› ° d ONLN dY ¥d ∫ )* f π] ° d ONLN dY ∫dU )"ields of the parameter block. The ˇ˛—∫ .ã ° d ONLN d'XVdz )úcsCode ˇˇh› .ã ° d ONLN d-YzdÄ )$ f gË ° d ONLN d/YÄd∞ ) ield specif °E ° d ONLN d:Y∞d
)0ies the type of contr ° d ONLN dOY d )[ol ° d ONLN dRe äp Í (m äinformation and the ° d ONLN dfd Íp )`csParam ° d ONLN dmep )* fi ° d ONLN dpe p )
7eld, which is up to 22 bytes long, contains the actual ° d ONLN dßq ä| † (y äcontr R` ° d ONLN d¨q †|O )$ol information. The Device Manager r $¿ ° d ONLN d–qO|– )Ø eserves some values for the $¿ ° d ONLN dÏp–|Ù )ÅcsCode $¿ ° d ONLN dÚqÙ|˜ )$ . ° d ONLN dÛ} äàH (Ö ä,parameter to indicate certain types of contr ç¿ ° d ONLN d }HàV )æol r 0† ° d ONLN d#}Wà| ) equests. ˇˇãΩ . ° d ONLN d-è äö ë (ó äY ï ° d ONLN d.è êö ˆ )ou can identify these r ñT ° d ONLN dEè ˆöc )fequests by checking the ˇˇz ≈H ° d ONLN d]écöá )mcsCode ˇˇãΩ ≈H ° d ONLN dcèáöê )$ fi Q ° d ONLN dfèëö )
. ° d ONLN d j l v ú ( s lkillCode . ° d ONLN d ) k ® v ≠ )<1 ° d ONLN d + k& vG )~KillIO r ˙† ° d ONLN d 3 kG vn )!equested . ° d ONLN d < v l Ç ñ ( lgoodBye . ° d ONLN d D w ® Ç ∞ )<-1 ° d ONLN d G w& Ç_ )~ Heap being r ¸@ ° d ONLN d S w_ Çê )9 einitialized . ° d ONLN d ` Ç l é ê ( ã laccRun . ° d ONLN d g É ® é ≤ )<65 ° d ONLN d j É& é, )~T ° d ONLN d k É, éí )ime for periodic action ° d ONLN d Ñ õ l ¶ Ë ( £ lWhen the Device Manager r p ° d ONLN d ù õ Ë ¶3 )|eceives a KillIO r ÉÄ ° d ONLN d Ø õ3 ¶a )K equest, it r ¶ ° d ONLN d ª õa ¶Í ). emoves every parameter block ° d ONLN d ÿ ß l ≤ s ( Ø lfr ò‡ ° d ONLN d ⁄ ß s ≤ µ )om the driver r ^ ° d ONLN d È ß ∂ ≤7 )C equest queue. If your driver r Ä ° d ONLN d ß8 ≤Å )Çesponds to any r @ ° d ONLN d ßÅ ≤« )Iequests asynchr 4@ ° d ONLN d& ß« ≤Í )Fonously êÄ ° d ONLN d- ßÈ ≤Ó )", ° d ONLN d/ ≥ l æ ( ª l(the part of your driver that completes r Ä ° d ONLN dW ≥ æ™ )≠ equests begun by the driver subr ` ° d ONLN dw ≥™ æfl )ë
ag in the ˇˇt™ R® ° d ONLN dA * ` ), drvrFlags ˇˇ∫U R® ° d ONLN dJ` s )6 wor fl] ° d ONLN dNs fl )d of your device header Q ° d ONLN de‡ ¯ )m, the ˇˇO® ° d ONLN dk
l ( l#Device Manager will call your Contr ‡® ° d ONLN dé
! )¶ol r ∞ ° d ONLN dí
"à )outine with the value ˇ˛üP AP ° d ONLN d® à≤ )fgoodBye ˇˇO® AP ° d ONLN dØ
≤— )* in the ˇ˛üP 0H ° d ONLN d∑ “ˆ ) csCode ˇˇO® 0H ° d ONLN dΩ
ˆ¯ )$ . ° d ONLN dæ l$ ≥ (! lparameter befor p† ° d ONLN dÕ ≥$ )Ge the heap is r ü ° d ONLN d‹ $& )=einitialized. æ ° d ONLN dÍ&$, )6Y ~† ° d ONLN dÎ,$O )ou can r ‡ ° d ONLN dÛP$Ò )$"espond by performing any clean-up ° d ONLN d% l0 — (- lactions necessary befor O ° d ONLN d,% “0 ı )fe heap r z‡ ° d ONLN d4% ı04 )#einitialization. ˇ˛Æ∞ . ° d ONLN dE7 lB ß (? lIf you set the ˇ˝]` :¿ ° d ONLN dT6 ®B fi )< dNeedTime ˇ˛Æ∞ :¿ ° d ONLN d]7 fiB Ê )6 fl Èp ° d ONLN d`7 ÊB )
ag in the ˇ˝]` ıÄ ° d ONLN dj6BE )) drvrFlags ˇ˛Æ∞ ıÄ ° d ONLN ds7EBW )6 wor vê ° d ONLN dw7XB¿ )d of your device header s ° d ONLN dé7¿B¯ )h
ets the value . ° d ONLN dÕª lΔ ë (√ lCONST ¢@ ° d ONLN d◊ª ëΔ Ø )%beepIt ‡ ° d ONLN d‡ª ØΔ … ) = 100; . ° d ONLN dÁÕ lÿ x (’ lin ° d ONLN dÍà xÿ ¥ )
the csCode ° d ONLN dÙÕ ¥ÿ æ )< fi ° d ONLN d˜Õ æÿ )
eld to indicate a r R` ° d ONLN d
ÕÿÇ )Tequest for system beeps. $¿ ° d ONLN d#ÕÇÿâ )pY 9¿ ° d ONLN d$ÕàÿΔ ) ou would defi 9¿ ° d ONLN d1ÕΔÿÈ )>ne this . ° d ONLN d9Ÿ l‰ Ë (· l constant in the constant defi ù¿ ° d ONLN dVŸ ˉn )| nition part of your Pascal unit. ˇˇùá . ° d ONLN dwÎ lˆ Ä (Û lThe ˇˇ; á ° d ONLN d{Í Åˆ √ ) DRVRControl ˇˇùá á ° d ONLN dÜÎ √ˆ+ )B function examines the ˇˇ; ì£ ° d ONLN dùÍ+ˆO )hcsCode ˇˇùá ì£ ° d ONLN d£ÎOˆX )$ fi 1* ° d ONLN d¶ÎYˆ¯ )
#eld of the parameter block for the ˇˇa¸ ° d ONLN d…ˆ l ê (ˇ lbeepIt ˇˇ∞˛ ° d ONLN dœ˜ ê À )$ value. If it f x ° d ONLN dfi˜ Ãè )<+inds this value, the function examines the ˇˇa¸ Îj ° d ONLN d ˆèπ )√csParam ˇˇ∞˛ Îj ° d ONLN d˜πø )* f lË ° d ONLN d˜¿¯ )
ield for the . ° d ONLN d l º ( lnumber of beeps r ÿ¿ ° d ONLN d0 º ˘ )Pequested, stor *‡ ° d ONLN d> ˙ )>es the r ”‡ ° d ONLN dFŒ ) (equested number in private storage, and ° d ONLN dn l u ( lpr G ° d ONLN dp v  )
: Integer; ° d ONLN d ª « ú ” ∫ ( – úBEGIN ° d ONLN d Δ ’ Æ ·n + IF (dce.dCtlStorage <> nil) THEN ° d ONLN d „ ¿ Ô fi +BEGIN ° d ONLN d ˝ Ò “ ˝Ê +.dStore := MyDriverGlobalsHdl(dce.dCtlStorage); ° d ONLN d7
“8 * CASE pb.csCode OF ° d ONLN dQ ‰'2 +
beepIt: BEGIN ° d ONLN dh) ˆ5ò +beepTimes := pb.csParam[0]; ° d ONLN dç7 ˆC *0dStore^^.numBeeps:= dStore^^.numBeeps+beepTimes; ° d ONLN d«E ˆQ *REPEAT ° d ONLN dÿS_J + SysBeep(1); ° d ONLN dÓam™ *beepTimes := beepTimes - 1; ° d ONLN do ˆ{z (x ˆUNTIL (beepTimes = 0); ° d ONLN d2} ‰â ¸ (Ü ‰END; ° d ONLN d>ã “ó Í (î “END; ° d ONLN dJô “•P *DRVRControl := NoErr; ° d ONLN dfß ¿≥ ÿ (∞ ¿END; ° d ONLN doµ ú¡ ∫ (æ úEND; . ° d ONLN duŒ äŸ Œ (÷ äThe Status subr ’ ° d ONLN dÑŒ ŒŸ} )D&outine should work in a similar manner · ° d ONLN d™Œ}Ÿ )Ø . The Device Manager uses the . ° d ONLN d»Ÿ äÂ Æ (‚ äcsCode ° d ONLN dŒ⁄ Æ µ )$ f PÄ ° d ONLN d–⁄ µÂç )0ield to specify the type of status information r "‡ ° d ONLN d ⁄çÂ∫ )ÿ
equested. ı@ ° d ONLN d
⁄π¿ ),Y
@ ° d ONLN d ⁄¿Âı ) our Status r ‹† ° d ONLN d⁄Ù )4outine . ° d ONLN d Ê äÒ ¡ (Ó ä should be pr 'Ä ° d ONLN d*Ê ¬Ò ’ )8epar ∏@ ° d ONLN d.Ê ’Ò Ò )ed to r Ä ° d ONLN d5Ê ÚÒP ) espond to whatever r † ° d ONLN dIÊPÒ| )^
equests ar NÄ ° d ONLN dSÊ|Òò ),e appr a` ° d ONLN dYÊòÒ ) opriate for your driver and ° d ONLN duÚ ä˝ ç (˙ är E ° d ONLN dvÚ é˝9 )&eturn the information in the csParam fi ÷@ ° d ONLN dùÚ9˝I )´eld. . ° d ONLN d¢ ä ( ä The Device Manager does not r R` ° d ONLN døM )è eserve any R` ° d ONLN d Mq )4csCode R` ° d ONLN d–qÍ )$ values for the Status subr $¿ ° d ONLN dÎÍ )youtine. ˇ˛Œo ° d ONLN dÛ ä ¥ ( äHowever ¬† ° d ONLN d˙ ≥4 )), when the Device Manager r ù+ ° d ONLN d4Å )Åeceives a Status r ⁄ÿ ° d ONLN d'Åø )Mequest with a ˇ˝úfi F% ° d ONLN d5¿‰ )?csCode ˇ˛Œo F% ° d ONLN d;‰ )$
value of 1, . ° d ONLN dH ä' ñ ($ äit r Ô¿ ° d ONLN dL ñ' ) eturns a handle to the driver †@ ° d ONLN di 'T )’s device contr ‡ ° d ONLN dx U'Å )@ ol entry fr Ê¿ ° d ONLN dÉ Ä'˛ )+ om the unit table. The driver _@ ° d ONLN d† ' )Ä’s ° d ONLN d£( ä3 £ (0 äContr Â@ ° d ONLN d®( £3 ¡ )ol subr S‡ ° d ONLN dØ( ¬3' ) outine never sees this r ü ° d ONLN d«('3F )eequest. ˇˇß . ° d ONLN dœ: äE π (B ä Listing 2-7 ' ° d ONLN d⁄: ∫E9 )0 shows a sample Status subr <¥ ° d ONLN dı:9EZ )outine, ˇˇN „¬ ° d ONLN d˝9ZEñ )!
DRVRStatus ˇˇß „¬ ° d ONLN d:ñE∞ )<. The ˇˇN 1fi ° d ONLN d
9±EÌ )
DRVRStatus ˇˇß 1fi ° d ONLN d:ÌE )<
function . ° d ONLN d!F äQ ç (N är E ° d ONLN d"F éQ
, you must pr 2† ° d ONLN d.∑‹¬˜ );ovide ° d ONLN d4√ lŒ7 (À l-a mechanism for your driver to complete the r ¿ ° d ONLN da√8Œ[ )Ãequests. ° d ONLN dj’ l‡ ¬ (› lSome examples of r ò† ° d ONLN d|’ ¬‡C )V outines that you might use ar +‡ ° d ONLN dô’D‡K )Çe: ,
Zapf Dingbats
° d ONLN dúÈ l q (Ô ln
° d ONLN dûÁ xÚ ≤ ) Completion r K@ ° d ONLN d™Á ≥Ú ÿ ); outines. ù ° d ONLN d≥Á ÿÚ fi )%Y ]Ä ° d ONLN d¥Á fiÚ! )our driver subr ∂¿ ° d ONLN d√Á!Ú˜ )C3outine could call another driver to start the data ° d ONLN dˆÛ x˛ ö (˚ xtransfer ° d ONLN d˛Û ö˛ )". In this case, you can pr
Ä ° d ONLN dÛ˛ß )j%ovide that driver with a completion r õ ° d ONLN d=Û߲ı )£outine. When the ° d ONLN dNˇ x
Û ( x other driver completes the r x ° d ONLN djˇ Û
‹ ){3equest, the Device Manager executes the completion ° d ONLN dù x { ( xr E ° d ONLN dû | Ò )outine. In the completion r π ° d ONLN dπ Òı )u=outine, you could call the other driver again to execute the ° d ONLN dˆ x"C ( x.next part of the I/O operation. When the entir ßÄ ° d ONLN d$C"Û )À(e operation is complete, the completion . ° d ONLN dL# x. | (+ xr R` ° d ONLN dM# |. ¡ )outine should r $¿ ° d ONLN d\# ¡.. )Eeturn by jumping to the $¿ ° d ONLN dt"..R )mIODone $¿ ° d ONLN dz#R.Y )$ r ˜ ° d ONLN d|#X.w )outine.
. ° d ONLN dÑ7 l> q (= ln
° d ONLN dÜ5 x@ ë ) Interr ç ° d ONLN då5 ë@ Œ )upt handlers. À@ ° d ONLN dö5 Œ@ ‘ )=Y ã¿ ° d ONLN dõ5 ‘@’ )=our driver might serve a device, such as a slot device, that ° d ONLN dÿA xL Ω (I xgenerates interr Δ` ° d ONLN dËA ΩL ’ )Eupts. † ° d ONLN dÓA ’L  )An @ ° d ONLN dÒA ÊL ) interrupt ` ° d ONLN d˙ALK )) causes the pr ˛‡ ° d ONLN dAJLÚ );%ocessor to suspend normal execution, ° d ONLN d-M xX ≥ (U x
save the addr ¿ ° d ONLN d:M ¥X )<ess of the next instr ‡ ° d ONLN dOM XU )Uuction and the pr Ä ° d ONLN d`MUXu )Locessor X` ° d ONLN dgMvXfl )!’s internal status on the ° d ONLN dÅY xd (a x stack, and execute an interr Ä ° d ONLN dùY Òd% )y upt handler ч ° d ONLN d®Y$d) )3. W@ ° d ONLN d™Y)d/ )Y ¿ ° d ONLN d´Y/dW ) ou can cr @ ° d ONLN d¥YWdë )(eate an interr I@ ° d ONLN d¬Yëd€ ):upt handler that ° d ONLN d”e xpï (m x@continues an I/O operation when the device signals, by an interr ˙Ä ° d ONLN deïp” (mïupt, that it is r 1` ° d ONLN d$e‘p˜ )?eady to ° d ONLN d,q x| £ (y x
° d ONLN d ] ñ h ¥ ) VBL, T É¿ ° d ONLN d ] ¥ h Ó ) ime Manager ^` ° d ONLN d ] Ó h" ): , and Deferr 'Ä ° d ONLN d ]# h6 )5ed T ¬† ° d ONLN d # ]5 h )1ask Manager tasks. Installing any of these tasks ° d ONLN d T i ñ t Æ ( q ñensur $ ° d ONLN d Y i Ø t )es that your driver r ùÄ ° d ONLN d n i t— )X.eceives system time at some point in the futur Ó† ° d ONLN d ú i— t ) e. During this ° d ONLN d ´ u ñ Är ( } ñ4time, you can check to see if the I/O operation is r † ° d ONLN d fl us Äø )›eady to continue.
ç H ö 4 é H ô
° d ONLN dˇˇ ( ï äNOTE
ˇ·ˇ‚7^
° d ONLN d Ò ò ä £ £ * Interr ç ° d ONLN d ˜ ò £ £1 ) upts can occur while your interr @ ° d ONLN d ò1 £Ω )é upt handler is executing. When ° d ONLN d6 § ä Ø° ( ¨ äAthis happens, it’s possible for the system to suspend your interr 3 ° d ONLN dw §¢ Ø≥ ( ¨¢upt ° d ONLN d{ ∞ ä ª ‘ ( ∏ ähandler for the fi @ ° d ONLN dç ∞ ’ ª ˚ )K
rst interr í@ ° d ONLN dó ∞ ˚ ª: )&upt and then r æ¿ ° d ONLN d• ∞: ªà )?eenter your interr ∑` ° d ONLN d∑ ∞à ªæ )N upt handler ° d ONLN d√ º ä « „ ( ƒ äfor the second interr ‡ ° d ONLN dÿ º ‰ « ¯ )Zupt. '‡ ° d ONLN d› º ¯ « ˛ )Y Ë` ° d ONLN dfi º ˝ «' )
our interr n† ° d ONLN dË º( «l )+upt handler is r á¿ ° d ONLN d¯ ºl «§ )Deentrant if it ° d ONLN d » ä ” ˝ ( – ähandles this situation corr dÄ ° d ONLN d" » ˝ ” )sectly <Ä ° d ONLN d' » ” ). ° d ONLN d* ⁄ ä  ê ( ‚ äT µ¿ ° d ONLN d+ ⁄ è  ≈ ) o help ensur T‡ ° d ONLN d7 ⁄ Δ Â$ )7e that your driver is r 6† ° d ONLN dN ⁄$ Â¥ )^!eentrant, your driver should stor † ° d ONLN do ⁄µ º )ëe ˇ˛; . ° d ONLN dq Ê ä Ò, ( Ó ä'a handle to its private storage in the ,
Courier ˇ¸v$ Xê ° d ONLN dò Â- Òo )£ dCtlStorage ˇ˛; Xê ° d ONLN d£ Êo Òw )B fi ì¢ ° d ONLN d¶ Êw Ò¡ )eld of the device . ° d ONLN d∏ Ú ä ˝ † ( ˙ äcontr >Ä ° d ONLN dΩ Ú ° ˝ √ )ol entry _¿ ° d ONLN d≈ Ú ¬ ˝° )!3, and not use memory within the driver code itself.
I ° d ONLN d˘ Ù• ¸™ )„u
° d ONLN d˚ äe ( ä2If your driver serves a device on an expansion car ›Ä ° d ONLN d-e» )€d, you might want to r K‡ ° d ONLN dC…˜ )d
espond to o ° d ONLN dM˜
).slot ° d ONLN dR ä ∑ ( ä
interrupts ` ° d ONLN d\ ∏ · ). , or interr ÖÄ ° d ONLN dg ·ù ))*upts signalled by devices on expansion car ˘‡ ° d ONLN dëùˇ )ºds. When a NuBus car * ° d ONLN d• )cd ° d ONLN dß ä' ¸ ($ ä device signals a slot interr M` ° d ONLN d√ ˝'∂ )s)upt, the CPU can quickly detect which car À ° d ONLN dÏ ∂'¬ )πd r +¿ ° d ONLN dÔ √'˝ )
equested the ° d ONLN d¸( ä3 ¢ (0 äinterr ° d ONLN d( £3c ),upt service, but not which device on the car XÄ ° d ONLN d.(c3t )¿d. T ™ ° d ONLN d2(s3 ) o determine which device caused ° d ONLN dR4 ä? ≥ (< ä
ent interr X ° d ONLN d R¨] ))upt, and, if so, calls the ° d ONLN d8^ äi ì (f äpr G ° d ONLN d:^ îi5 )
%oper driver code to handle the interr < ° d ONLN d_^5i )°1upt. The Slot Manager maintains a queue of these ° d ONLN dêj äu ∞ (r ä polling r V@ ° d ONLN dôj ∞u
)&outines for each slot. ÃÄ ° d ONLN d∞j
u )]Y ç ° d ONLN d±ju ):our driver can install an element in this queue using the ˇˇD . ° d ONLN dÎv äÅ Õ (~ äSlot Manager r bË ° d ONLN d˘v ÕÅ Î )Coutine ˇ˛à k, ° d ONLN d u ÎÅ- ) SIntInstall ˇˇD k, ° d ONLN d v-Å2 )B. E– ° d ONLN d
v2Å9 )Y Z– ° d ONLN dv8Ån )
ou can also r E¸ ° d ONLN dvnÅ )6$emove a queue element with the Slot ˇˇ ° d ONLN d?Ç äç ∏ (ä ä Manager r oP ° d ONLN dHÇ ∏ç ÷ ).outine ˇ˛9‡ å@ ° d ONLN dOÅ ÷ç )
SIntRemove ˇˇ å@ ° d ONLN dYÇç )<7. The chapter “The Slot Manager” in this book gives mor ° d ONLN dêÇç )ˇe ° d ONLN díé äô Ú (ñ äinformation about the ° d ONLN d®ç Úô4 )h SIntInstall ° d ONLN d≥é4ôK )B and ° d ONLN d∏çKôá )
SIntRemove ° d ONLN d¬éáôé )< r R` ° d ONLN dƒééô± )outines. . ° d ONLN dÕ† ä´ ≠ (® äFor mor ¿ ° d ONLN d‘† Æ´% )$ e information on slot interr E‡ ° d ONLN d†%´Î )w/upts and writing drivers for slot devices, see ° d ONLN d ¨ ä∑j (¥ ä4Designing Cards and Drivers for the Macintosh Family ∑ ° d ONLN dS¨i∑k )fl.
› H„ 4› H‚ › ä›
ˇ·ˇ‚7^
ˇˇ◊ ˇ◊ ° d ONLN dUÃ ä‹ (ÿ äInstalling the Driver ˇˇˇˇˇˇ • (ÿ2
° d ONLN dk„ äÓ< (Î ä%When you have completed your driver r Ά ° d ONLN dê„<ÓT )≤esour 3‡ ° d ONLN dï„UÓ˘ )%ce, you have a number of options for ° d ONLN d∫Ô ä˙ (˜ ä$storing it and installing the driver @ ° d ONLN dfiÔ ˙* )ï. T O ° d ONLN d·Ô)˙ü )
wo of the most common ar §¿ ° d ONLN d˘Ôü˙¶ )ve:
° d ONLN d¸ ä
è ( än
° d ONLN d˛ ñ Í ) Storing the driver r .¿ ° d ONLN d Î )Uesour w ° d ONLN d ˙ );ce in an application and having the application install it.
° d ONLN dS ä è ( än
° d ONLN dU ñ Í ) Storing the driver r .¿ ° d ONLN di Î )Uesour w ° d ONLN dn u )ce in a system extension fi ` ° d ONLN dâv ˛ )s!le and writing an initialization . ° d ONLN d™ ñ* ö (' ñ( ° d ONLN d´ ö* æ )'INIT' ° d ONLN d± æ* … )$) r R` ° d ONLN d¥ …* ‡ ) esour $¿ ° d ONLN dπ ‡*% )ce to install it. . ° d ONLN dÀ1 ä<T (9 ä/In either case, you need to write code to ensur Q‡ ° d ONLN d˙1U<• )Àe your driver is pr _† ° d ONLN d
1•< )Poperly installed and ° d ONLN d "= äH ƒ (E ä opened befor ◊† ° d ONLN d .= ƒH4 ):e making sending it any r Z ° d ONLN d G=5HZ )q equests. ` ° d ONLN d P=[Ha )&Y ‹‡ ° d ONLN d Q=`Hà ) ou can cr –` ° d ONLN d Z=àHŸ )(eate a device contr í` ° d ONLN d m=⁄H˛ )R ol entry ˇ˛√¬ . ° d ONLN d vI äTÉ (Q ä;yourself and install it in the unit table and then use the ˇ˝áÑ ≠ ° d ONLN d ±HÉTß )˘PBOpen ˇ˛√¬ ≠ ° d ONLN d ∑IßT≥ )$ or ˇ˝áÑ 4ú ° d ONLN d ªH¥T‰ )
OpenSlot ˇ˛√¬ 4ú ° d ONLN d √I‰T )0
function to ° d ONLN d –U ä` (] ä open it, or you can use the ° d ONLN d ÏT`A ){
OpenDriver ° d ONLN d ˆUA`– )<! function to install and open it. . ° d ONLN d
g ärÅ (o ä<If you want to install the driver yourself, see the section x† ° d ONLN d
TgÇr™ )¯ “Data Str Y ° d ONLN d
]g´r¬ ))uctur fi‡ ° d ONLN d
bg¬r )es” on page 2- [ ° d ONLN d
pgr )?34 [ ° d ONLN d
rg r
)
° d ONLN d
ss ä~ ({ ä"for details about the device contr Ň ° d ONLN d
Ö,ê∂ )< function to install your driver ™ ° d ONLN d
ÍÖ∂êÿ )ä, you ar 2Δ ° d ONLN d
ÚÖŸê‰ )#e r ¬Ñ ° d ONLN d
ıÖ‰ê ) esponsible . ° d ONLN d ë äú (ô ä7for examining the unit table and changing your driver r ÷@ ° d ONLN d 7ëúó )ıesour Ä ° d ONLN d <ëòú· )ce ID so that the . ° d ONLN d Nú ä® Δ (• ä
OpenDriver ° d ONLN d Xù Δ® )<J function install your driver in an empty location in the unit table. The ° d ONLN d ¢® ä¥ Δ (± ä
° d ONLN d o l z ˘ ( w l!The unit table is a 256-byte nonr 4@ ° d ONLN d ! o ˙ zm )éelocatable block of 64 four ã¿ ° d ONLN d < om z‹ )s-byte spaces that contain ° d ONLN d V { l Ü “ ( É lhandles to device contr —¿ ° d ONLN d m { “ Ü„ )f@ol entries for installed drivers. If needed, the Device Manager ° d ONLN d ≠ á l íÈ ( è lVautomatically expands the unit table to a maximum of 128 entries. The global variable ,
Courier . ° d ONLN d í l û ® *
UTableBase ° d ONLN d
ì ® û )< contains the base addr R` ° d ONLN d$ ì ûu )kess of the unit table. . ° d ONLN d< • l ∞€ ( ≠ lUFor an entry in the unit table to be suitable it must be empty—that is, contain a NIL Q ° d ONLN dë •€ ∞› ( ≠€ ° d ONLN dí ± l º Ï ( π l pointer—and it must not be r A‡ ° d ONLN dÆ ± Ì º )Å eserved. ê` ° d ONLN d∑ ± º )'T Δ ° d ONLN d∏ ± º; )able 2-1 ”† ° d ONLN d¿ ±; ºÈ )"& shows a summary list of unit numbers ° d ONLN dÊ Ω l » o ( ≈ lr E ° d ONLN dÁ Ω p » ¿ )eserved for specifi Ω† ° d ONLN d˙ Ω ¿ » Ú )P c purposes:
Î * Û¯ 4 Ï * Û¯ Ô l Ô¯
ˇ·ˇ‚7^
° d ONLN dˇˇ ( È l Table 2-1 ° d ONLN d · ™ Ï )>Reserved unit numbers ° d ONLN d ˘ l ø ( lUnit Number Range ° d ONLN d1 ˘ – )d RefNum Range ° d ONLN d> ˘4X )dPurpose
-opening r ` ° d ONLN d„äÖï„ ).outine in the chapter . ° d ONLN d˘ñ l°É (û l;“The Device Manager” calls this function and then uses the ° d ONLN d4ïÉ°ø (ûÉ
OpenDriver ° d ONLN d>ñø°ı )<
function to . ° d ONLN dK¢ l≠ (™ l"install and open the device driver 0¿ ° d ONLN dm¢ ≠ )î.
Û *˜¯ 4Ù *ˆ¯ "Ù *a
ˇ·ˇ‚7^
° d ONLN dˇˇ (Ò l Listing 2-9 ° d ONLN doÈ ∞Ù Ù )DInstalling a driver
. ° d ONLN dÖ l t ( l,FUNCTION FindEmptySpaceInUnitTable: Integer; ° d ONLN d∂ ~ ñ +TYPE ° d ONLN d¿ ê( ∫ +WordPtr ° d ONLN d… ∫( ¸ )* = ^Integer; ° d ONLN d€8 ~D ú (A ~CONST ° d ONLN dÊF êR Ã +
UTableBase ° d ONLN dÒF ÃR ˆ )<= $11C; ° d ONLN d˛T ê` “ (] ê UnitNtryCnt ° d ONLN d
T “` ¸ )B= $1D2; ° d ONLN dp ~| ê (y ~VAR ° d ONLN d!~ êä ∫ +dRefNum ° d ONLN d*~ ∫ä ˆ )*
: Integer; ° d ONLN d:å êò Æ (ï êcount ° d ONLN dAå ¥ò )$
: Integer; ° d ONLN dQö ê¶ ¿ (£ êfoundOne ° d ONLN dZö ¿¶ ¸ )0
: Boolean; ° d ONLN dj® ê¥ ¢ (± êdce ° d ONLN dp® Δ¥ )6
: DCtlHandle;
\ l i1 , Times . ° d ONLN dˇˇ ( e mU ?ß ° d ONLN dˇˇ )n «. ° d ONLN dˇˇ )i ı ° d ONLN dˇˇ )t dº ° d ONLN dˇˇ )N ó√ ° d ONLN dˇˇ )u J ° d ONLN dˇˇ )m fiÒ ° d ONLN dˇˇ )b fx ° d ONLN dˇˇ )e ^? ° d ONLN dˇˇ )r
{| ° d ONLN dˇˇ )1 , Symbol 2_ ° d ONLN dˇˇ ( e ≤-
. ° d ONLN d j ú v ∫ ( s úBEGIN ° d ONLN d x ä Ñ ê ( Å ä ° d ONLN d x Æ Ñt )$!{Get negative number of entries.} ° d ONLN d 3 Ü Æ ít *!count := - WordPtr(UnitNtryCnt)^; ° d ONLN d b ¢ Æ Æ * dRefNum := -49; ° d ONLN d v ¢ Æ⁄ )Z#{first unreserved reference number} ° d ONLN d ° æ Æ ( « ÆfoundOne := FALSE; ° d ONLN d π Ã Æ ÿ¬ *.WHILE ( (dRefNum > count) AND NOT foundOne) DO ° d ONLN d Ó ⁄ ¿ Ê fi +BEGIN ° d ONLN d ˚ Ë “ ÙÄ + dce := GetDCtlEntry(dRefNum); ° d ONLN d ˆ “D *IF (dce = nil) THEN ° d ONLN d< ‰D +foundOne := TRUE ° d ONLN dT “ Í ( “ELSE ° d ONLN da ‰,n +dRefNum := dRefNum - 1; ° d ONLN d. ¿: ÿ (7 ¿END; ° d ONLN dãJ ÆVJ (S ÆIF (foundOne = FALSE) THEN ° d ONLN d¨X ¿d fi +BEGIN ° d ONLN dπf “rP +{make a larger table} ° d ONLN d’t ¿Ä ÿ (} ¿END; ° d ONLN d‡ê ÆúŒ (ô Æ0FindEmptySpaceInUnitTable := -1 * (dRefNum + 1); ° d ONLN dû ú™ ¥ (ß úEND;
Á H 4Ë H
H 4 H H
ˇ·ˇ‚7^
ˇˇ£‰ . ˇÆ ° d ONLN d H X ( HW œ ° d ONLN d Xö ))riting a Chooser-Compatible Device Driver ˇˇˇˇˇˇ ⁄| ( 2
° d ONLN dE$ ä/Q (, ä-The Chooser is a desk accessory that helps pr ⁄` ° d ONLN dr$Q/ï )«ovide a standar ı` ° d ONLN dÅ$ï/
)D d user interface for device ° d ONLN dù0 ä;- (8 ä'drivers. It allows device drivers to pr ‘Ä ° d ONLN dƒ0-; )£4ompt the user for choices such as which serial port ° d ONLN d¯< äG « (D äto use, which 9† ° d ONLN d< «G Ë )=AppleT χ ° d ONLN d < ÁGƒ ) .alk zone to communicate with, and which LaserW ·‡ ° d ONLN d:<ƒGˆ )›
riter to use. ° d ONLN dHN äY (V ä#If your device driver can serve dif
° d ONLN dkN Y, )ñfer ÔÄ ° d ONLN dnN+YJ ) ent har „@ ° d ONLN duNJYa ) dwar ° d ONLN dyNbYÆ )e devices or confi {Ä ° d ONLN dãNÆY )Lgurations, you may ° d ONLN dûZ äe (b ä want to use the Chooser to pr Ÿ` ° d ONLN dªZ e€ )Ç0ovide an interface for the user to make choices. ° d ONLN dÏl äw ê (t äY @Ä ° d ONLN dÌl êw ¬ ) ou should r @ ° d ONLN d¯l √w Ô )3
ˇˇ◊ ˇ◊ ° d ONLN d ] l m ˘ ( i lHow the Chooser W ˘= ° d ONLN d ] ¯ m )åorks ˇˇˇˇˇˇ • )¯2
° d ONLN d t l ◊ ( | lQThe Chooser allows users to select which devices they want to use. When the user ° d ONLN d g Ä l ã * #launches the Chooser desk accessory ‰@ ° d ONLN d ä Ä
ãÅ )°, the Chooser displays the c` ° d ONLN d • ÄÇ ã– )uChooser window Ć ° d ONLN d ≥ Äœ ã— )M, † ° d ONLN d ¥ Ä“ ãÚ ) which ° d ONLN d ª å l ó6 ( î l.contains lists and buttons for making device-r ∞† ° d ONLN d È å6 ó~ ) elated choices. T [Ä ° d ONLN d ˙ å~ ó° )Hypically âÄ ° d ONLN d å† ó˜ )", users select a type ° d ONLN d ò l £ ù ( † l of device fr ° d ONLN d$ ò û £ ø )2om the 7 ° d ONLN d+ ò ø £ „ )! icon list ë‡ ° d ONLN d4 ò „ £… )$7, then select the particular device they want to use fr fi¿ ° d ONLN dk ò… £Í )Êom the ° d ONLN dr § l Ø ü ( ¨ l
device list. ⁄‡ ° d ONLN d § ü Ø ∞ )3For Û¿ ° d ONLN dÉ § ∞ Ø — )AppleT ß ° d ONLN dâ § — Ør )!&alk devices, they must also select an IÄ ° d ONLN dØ §r Øì )°AppleT ¸¿ ° d ONLN dµ §í Ø¿ ) alk zone fr ù† ° d ONLN d¿ §¡ Ø‚ )/om the ° d ONLN d« ∞ l ª ï ( ∏ l
zone list. ñ¿ ° d ONLN d— ∞ ï ª‡ ))H The Chooser window can also display buttons, such as an OK button, and ° d ONLN d º l « ( ƒ l!radio buttons, such as the LaserW {` ° d ONLN d: º « )ïriter ` ° d ONLN d? º «< ) ’s backgr q¿ ° d ONLN dH º< «´ )'ound printing On and Of ±¿ ° d ONLN d_ º´ «‘ )o
f buttons. ° d ONLN dj Œ l Ÿ Ñ ( ÷ lFigur R¿ ° d ONLN do Œ Ñ Ÿ; )%e 1-4 shows an example Chooser window ÆÄ ° d ONLN dî Œ: Ÿ? )∂.
¸ *
¯ 4 ˝ *
¯ " ˝ *_
ˇ·ˇ‚7^
° d ONLN dˇˇ ( ˙ l
Figure 2-2 ° d ONLN dó Ú Æ ˝ )BThe Chooser window
° d ONLN d™ÿ l„ ™ (‡ l
The Chooser r Õ` ° d ONLN d∑ÿ ™„V )>(elies heavily on the List Manager for cr ∫Ä ° d ONLN dflÿV„Ω )¨eating, displaying, and ° d ONLN d˜‰ lÔV (Ï l4manipulating possible user selections in this window w ° d ONLN d+‰VÔ[ )Í. I` ° d ONLN d-‰[Ôa )Y ‡ ° d ONLN d.‰aÔ¨ )ou may want to r —@ ° d ONLN d>‰¨Ô· )K
ead the List ° d ONLN dK l˚ ’ (¯ lManager chapter in the ÎÄ ° d ONLN db ’˚% )iInside Macintosh: T ÕÄ ° d ONLN du%˚> )Poolbox ÜÄ ° d ONLN d{?˚á ) volume for mor y‡ ° d ONLN däá˚≈ )He information. ° d ONLN dô l
(
l$The Chooser does not communicate dir =Ä ° d ONLN dΩ
π )Æ'ectly with device drivers; instead, it ° d ONLN d‰ l ( l#communicates with device packages. A¿ ° d ONLN d )¶A |` ° d ONLN d ) ¸` ° d ONLN d ` )device package "@ ° d ONLN dax )F is a r å† ° d ONLN d xê )esour ‘‡ ° d ONLN d#êÌ )ce similar to a driver ° d ONLN d: l% o (" lr E ° d ONLN d; p% à )esour ç@ ° d ONLN d@ à% ) ce, except a device package r ‡ ° d ONLN d]%€ ).esponds to Chooser messages instead of Device ° d ONLN dã& l1 ö (. l Manager r W ° d ONLN dî& ö1& ). equests. The device package is r ı ° d ONLN d¥&&1— )å%esponsible for communicating the user E ° d ONLN dŸ&”1‹ )≠’s ° d ONLN d‹2 l= ‰ (: l choices to the device driver u` ° d ONLN d¯2 ‰= Ê )x. ° d ONLN d˙D lO ¿ (L lDevice packages ar +† ° d ONLN d D ¡O Ÿ )Ue stor / ° d ONLN dD ŸO Ò )ed in Œ@ ° d ONLN dD ÒOM )Chooser extension fi é† ° d ONLN d,DNOZ )]les R¿ ° d ONLN d/D[O„ )
, which the Chooser expects to ° d ONLN dNP l[ r (X lfi å¿ ° d ONLN dPP r[ )#nd in the System Folder of the user ¶` ° d ONLN dsP
[Ω )õ(’s startup disk. The Chooser extension fi âÄ ° d ONLN dúPæ[˜ )±le contains a ° d ONLN d™\ lg † (d l number of r ˛¿ ° d ONLN dµ\ †g ∏ )4esour G ° d ONLN d∫\ πga )'ces in addition to the device package r ÎÄ ° d ONLN d·\agy )®esour 3¿ ° d ONLN dÊ\zg¬ )ce. These other r :Ä ° d ONLN d˜\¬g⁄ )Hesour Ç¿ ° d ONLN d¸\⁄gÈ )ces ° d ONLN d h ls< (p l/allow you to specify information to the chooser ^` ° d ONLN d/h<s¡ )– . For example, you can specify ,
Zapf Dingbats
° d ONLN dN| lÉ q (Ç ln
° d ONLN dPz xÖ ã ) The ª¿ ° d ONLN dTz ãÖ Í )device list box label. Ö ° d ONLN dkz ÎÖÕ )`5The Chooser displays this label over the device list.
° d ONLN d°é lï q (î ln
° d ONLN d£å xóË ) RWhich buttons to use. The Chooser allows the device package to display up to four ° d ONLN dıò x£ À * buttons, called the ° d ONLN d ò ã ˇ )T Left button xÄ ° d ONLN dò ˇ£ )3, the ’‡ ° d ONLN dò£N ) Right button j¿ ° d ONLN d&òO£d );, the » ° d ONLN d,òd£≠ )On radio button §@ ° d ONLN d;òÆ£÷ )J
, and the n¿ ° d ONLN dEò◊£„ ))Of x† ° d ONLN dGò„£È ) f ° d ONLN dI§ xØ ∞ (¨ x radio button lÄ ° d ONLN dU§ ±Ø ≥ )9.
Å Å ª ◊™ ∂ Å◊Ö◊™ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ ò 4 @ù @ù– l Õ Õ Õ Õ Õ Õ Õ Õ ı Ü ?Ä !ˇ 0˝ 0 ı B˛ b% ˚ ı "("(˛ †" ˚ ı %("H#èÀf CÜ8aéfÃú–„2@Ú ı %HBê<íI™@BJ
˛êêê @ù– l Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Jù ˇ˛˛ˇ˝ ˛ˇ˝ ˇˇ˛˚ ˇ˛˚ ˇ¸ ˛ˇ ˛˛ˇ‰ ˇˇ˜ ˇ˝ ˇˇ˛˛ˇ˛ˇˇÔ ˇˇÿ ˛ı ˇˇÅ ˜ Gú ˇ˛ ˇ˝ ˇ˝ ˇˇ˚ ˇ ˇ˝ ˇˇ˚ ˇ˛ ˇ‚ ˇ¯ ˇˇ˛ ˇ˛ ˇ ˇ ˇÓ ˇ ˇÅ ˜ Bú ˇ˝ ˇ˛ ˇ˛ ˇ ˇ¸ ˇ˛ ˇ˛ ˇ ˇ˚ ˇfi ˇ˘ ˇ ˇ˙ ˇ˛ ˇÓ ˇ… ˇÅ ˜ •ù ˇ¸
Å fi ˛ˇÅ â Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ ö ˇÛ ˇˇÙ ˛ˇ ˇ’ ˛ˇÅ ú õ ˇ˛Ú ˛ı ˇ˛ ˇ” ˛Å õ õ ˇˇÚ ˇˆ ˇ˝ ˇ‰ ˇÒ ˇÅ õ Xú
ˇ ˇˇ ˛ˇˇ ˛ˇ ˛˝ ˇ ˇ˛ ˇˇ˛ ˇ˛˛ ˛˙ ˛ˇ˝ ˇ ˇˇÅ Ö Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ òÅû Ä ¿ù H H Qbê "Ä ˛ ˇˇˇˇˇˇ ˇˇˇˇÃà ˇˇˇˇôô ˇˇˇˇff ˇˇˇˇ33 ˇˇˇˇ ˇˇÃÃˇˇ ˇˇÃÃÃà ˇˇÃÃôô ˇˇÃÃff
˛êêê Ä ¿ùR lí Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ Å Å Å „ ˇ‹ @ ˇ ˇˇˇˇ @
ches the curr £Ä ° d ONLN d Ö Åµ å≈ )8ent ¢Ä ° d ONLN d â Å≈ åÊ )AppleT U¿ ° d ONLN d è ÅÊ å
)! alk zone ° d ONLN d ò ç ñ ò ¸ ( ï ñfor devices of this type.
° d ONLN d ≤ ° ä ® è ( ß än
° d ONLN d ¥ ü ñ ™ ¶ ) An :@ ° d ONLN d ∑ ü ¶ ™ « )AppleT ÌÄ ° d ONLN d Ω ü Δ ™# ) alk Name-Binding Pr Æ ° d ONLN d – ü$ ™_ )^
otocol (NBP) ≈† ° d ONLN d › ü_ ™ö );retry interval z ° d ONLN d Î üõ ™∏ )< and a Á ° d ONLN d Ú ü∏ ™¸ ) timeout count. | ° d ONLN d ü˝ ™ )EThe ° d ONLN d ´ ñ ∂J ( ≥ ñ'Chooser uses this information when sear ö‡ ° d ONLN d, ´J ∂t )¥
ching for É ° d ONLN d6 ´t ∂ï )*AppleT 6@ ° d ONLN d< ´ï ∂» )! alk devices. ° d ONLN dI √ ä Œ ( À ä!When a user selects the icon corr Ø@ ° d ONLN dj √ Œ )ê6esponding to a particular device package, the Chooser ° d ONLN d† œ ä ⁄È ( ◊ äPsends messages to that device package by calling the device package as if it wer Ñ ° d ONLN d œÈ ⁄ ( ◊Èe the ° d ONLN dˆ € ä Ê fi ( „ äfollowing function: ,
Courier . ° d ONLN d
Ú ä ˛ Í *FUNCTION Package ° d ONLN d" Ú Í ˛å )` (message, caller: Integer; ° d ONLN dG ˆ § + objName, zoneName: StringPtr; ° d ONLN dn ˆå *p1, p2: LongInt) : OSErr;
) H6 4* H5
. ° d ONLN dˇˇ (1 äNOTE
ˇ·ˇ‚7^
° d ONLN dà4 ä? · * Like the driver subr $@ ° d ONLN dú4 ‚?≥ )X.outine names, the name Package for the device ° d ONLN d @ äK ¥ (H ä package r @ ° d ONLN d”@ µK5 )+ outine is a descriptive name. “¿ ° d ONLN dÒ@5K; )ÄY ì@ ° d ONLN dÚ@;K∏ )ou can choose any name for ° d ONLN d
L äW (T ä your actual device package r ̆ ° d ONLN d)LWö )~ outine—the Chooser locates the r ìÄ ° d ONLN dILõWπ )ìoutine ° d ONLN dPX äc9 (` ä&using the device package header you pr 8` ° d ONLN dvX:cW )∞ovide.
terminateMsg ° d ONLN dù‚Ó& )N= ° d ONLN d†‚&Ó8 ) 17; ° d ONLN d•‚8Ó )$ {allows device package to clean up} ° d ONLN dœÓ Ã˙ (˜ à buttonMsg ° d ONLN d‹Ó˙ )6 = ° d ONLN d‡Ó˙, )18; ° d ONLN d‰Ó,˙2 ) ° d ONLN dÁÓ2˙Œ ) {user selected a button} . ° d ONLN dˇ Ã
( Ã The section $@ ° d ONLN dˇ
≥ )5&“Responding to the Chooser” on page 2- fi ° d ONLN d5ˇ≥
Ω )≤27 fi ° d ONLN d7ˇΩ
)
explains these ° d ONLN dG à ( Ãmessages in mor ı† ° d ONLN dV 7 )I e detail. . ° d ONLN d` ä& Æ (# äcaller . ° d ONLN dg Ã& Ï )BIdentifi ÿ ° d ONLN do Ï& )
es the caller † ° d ONLN d| &$ )3. í@ ° d ONLN d~$&+ )A Ç ° d ONLN d+&∫ )! value of 1 indicates the Chooser Y` ° d ONLN d†∫&Δ )è. V ¶Ä ° d ONLN d£≈&˙ )
alues in the ° d ONLN d∞' Ã2 (/ Ãrange 0 to 127 ar † ° d ONLN d¡'2 )Ie r (@ ° d ONLN dƒ' 2ˇ ) 2eserved; values outside this range may be used by ° d ONLN dˆ3 Ã> (; Ã
applications. . ° d ONLN dB äN ∫ (K äzoneName . ° d ONLN d
C ÃN )BContains name of q ° d ONLN d C N= )PAppleT $@ ° d ONLN d$C=N )!.alk zone containing the devices in the device ° d ONLN dRO ÃZ˚ (W ÃIlist. If the Chooser is being used with the local zone and bit 24 of the ˇ¸‚6 . ° d ONLN dõZ Ãf Í * flags ˇ˛q ° d ONLN d†[ Íf Ô ) f ¡õ ° d ONLN d¢[ Ôf )Bield of the device package header is not set, the string value is fl ° d ONLN d‰[f (c'*'; . ° d ONLN dÈg Ãr± (o Ã6otherwise, it’s the actual zone name. See the section R` ° d ONLN d g≤r¬ )Ê“Cr .` ° d ONLN d"g¬r )eating a Device ° d ONLN d2s Ã~% ({ ÃPackage” on page 2- W` ° d ONLN dEs&~0 )Z26 W` ° d ONLN dGs0~S )
for mor !‡ ° d ONLN dOsT~ )$&e information about the package header Z¿ ° d ONLN dus~ )Ø. . ° d ONLN dwÇ äé ñ (ã äp1 . ° d ONLN dzÉ Ãé )BLContains a handle to the List Manager list that contains the device choices ° d ONLN dΔè ÃöY * "displayed in the device list box. ˇ#Ä @ ˇ ˇˇˇˇ @
. ° d ONLN d \ l h ñ ( e lobjName . ° d ONLN d ] Æ hÏ )BEContains other information. The meaning of this parameter depends on ˇ˛∫q . ° d ONLN d M i Æ t ˜ * the value of the ˇ˝t‚ iƒ ° d ONLN d ^ h ¯ t" )Jmessage ˇ˛∫q iƒ ° d ONLN d e i" tS )*
parameter f’ ° d ONLN d o iS ti )1. See €∑ ° d ONLN d u ii t˜ ) “Responding to the Chooser” on . ° d ONLN d î u Æ Ä Œ ( } Æpage 2- Æ¿ ° d ONLN d õ u Œ Ä ÿ ) 27 Æ¿ ° d ONLN d ù u ÿ Ä ˚ )
for mor y@ ° d ONLN d • u ¸ Ä8 )$
e information . ° d ONLN d ≥ Ñ l ê x ( ç lp2 ° d ONLN d µ Ö x ê { ) . ° d ONLN d ∑ Ö Æ êÏ )6EContains other information. The meaning of this parameter depends on ˇ˛∫q . ° d ONLN d ¸ ë Æ ú ˜ * the value of the ˇ˝t‚ iƒ ° d ONLN d
ê ¯ ú" )Jmessage ˇ˛∫q iƒ ° d ONLN d ë" úS )*
parameter f’ ° d ONLN d ëS úi )1. See €∑ ° d ONLN d$ ëi ú˜ ) “Responding to the Chooser” on . ° d ONLN dC ù Æ ® Œ ( • Æpage 2- Æ¿ ° d ONLN dJ ù Œ ® ÿ ) 27 Æ¿ ° d ONLN dL ù ÿ ® ˚ )
for mor y@ ° d ONLN dT ù ¸ ®8 )$
e information ° d ONLN db µ l ¿ ( Ω l When the user opens the Chooser Ü` ° d ONLN dÅ µ ¿N )î, the Chooser sear ¸ ° d ONLN dì µN ¿fl )N"ches the Extensions folder in the ° d ONLN dµ ¡ l Ãj ( … l9System Folder of the startup disk for Chooser extension fi ∂¿ ° d ONLN dÔ ¡j à )˛les. For each one it fi @ ° d ONLN d ¡ƒ ÷ )Znds, it ˇ˛ãë . ° d ONLN d Õ l ÿ ü ( ’ l opens the fi ó" ° d ONLN d Õ ü ÿQ )3+le, fetches the device’s icon, fetches the ˇ˝" h ° d ONLN dE ÃR ÿp )≥flags ˇ˛ãë h ° d ONLN dJ Õp ÿx ) fi Û™ ° d ONLN dM Õx ÿê )eld fr Qõ ° d ONLN dS Õë ÿ¯ )om the device package . ° d ONLN di Ÿ l ‰ ä ( · lheader 5† ° d ONLN do Ÿ ä ‰ ’ ) , and closes the fi û† ° d ONLN dÇ Ÿ ’ ‰„ )K>le. The Chooser then displays each device’s icon, graying the ° d ONLN d¿  l î ( Ì l
icons for ∫ ° d ONLN d Â î µ )(AppleT m` ° d ONLN d–  µ Ò )!alk devices if -† ° d ONLN dfl Â Ò )<AppleT ‡‡ ° d ONLN d  k ) alk is not connected. ° d ONLN d˚ ˜ læ ( ˇ lMWhen the user selects a device package icon that is not grayed, the Chooser r ° d ONLN dH ˜ø ( ˇø eopens the ° d ONLN dS l } ( lcorr ` ° d ONLN dW ~ ) esponding Chooser extension fi f‡ ° d ONLN du { )ãle and does the following: ° d ONLN dë n u ( n1. ° d ONLN dî x † )
FThe Chooser labels the device list box with the device list box label. ° d ONLN d‹' n2 u (/ n2. . ° d ONLN dfl' x2 „ )
The Chooser sends the ° d ONLN dı& „2 ˚ )kinit ° d ONLN d˘' ˚2∫ )) message to the selected device package. . ° d ONLN d$9 nD u (A n3. ° d ONLN d'9 xD )
If the selected device package r ≠Ä ° d ONLN dG9D )âepr >@ ° d ONLN dJ9Dn )esents a serial printer ô ° d ONLN da9mD„ )] , the Chooser places in the ° d ONLN d}E xP (M x$device list box the two icons that r † ° d ONLN d°EP )óepr ò` ° d ONLN d§E PÙ )1esent the printer port and the modem port serial ° d ONLN d’Q x\m (Y x7drivers. When the user makes a selection, the Chooser r S† ° d ONLN d Qm\ )ıecor » ° d ONLN dQ\Ø ) ds the user ª‡ ° d ONLN dQ∞\ˆ )1’s choice in low ° d ONLN d,] xh ˝ (e xmemory and parameter RAM. ° d ONLN dGo nz u (w n4. ° d ONLN dJo xz )
If the selected device package r ≠Ä ° d ONLN djoz )âepr >@ ° d ONLN dmoz: )
esents an “@ ° d ONLN dwo:z[ )*AppleT ÖÄ ° d ONLN d}o[z‰ )! alk device and does not accept ˇ˛\ . ° d ONLN dúz xÜ ® (É xfillList ˇˇ
Æ ° d ONLN d§{ ®Ül )0+ messages, the Chooser initiates an asynchr §t ° d ONLN dœ{lÜä )ƒonous r ÑÇ ° d ONLN d÷{äÜŸ ) outine that interr r> ° d ONLN dË{ŸÜ¯ )Oogates . ° d ONLN dÔá xí ö (è xthe curr ` ° d ONLN d˜á õí ´ )#ent ` ° d ONLN d˚á ´í à )AppleT æ† ° d ONLN dá Àíû ) 0alk zone for all devices whose type matches the ]† ° d ONLN d1áüí¿ )‘AppleT ‡ ° d ONLN d7á¿íÔ )! alk device ° d ONLN dBì xû ≈ (õ xtype name specifi ˙` ° d ONLN dSì ≈ûH )M ed in the Chooser extension fi ° d ONLN dqìIûã )Ñle. The asynchr û ° d ONLN dÄìãû¨ )Bonous r „Ä ° d ONLN dáì¨û )!outine uses the ° d ONLN dóü x™ { (ß xr E ° d ONLN dòü |™ )%etry interval and the timeout count. ç‡ ° d ONLN dΩü™- )üAs r ◊ ° d ONLN d¡ü-™‰ ))esponses arrive, the Chooser updates the ° d ONLN dÍ´ x∂ π (≥ xdevice list box. ° d ONLN d¸Ω n» u (≈ n5. ˇˇÿù . ° d ONLN dˇΩ x»@ )
, If the selected device package does accept ˇˇ±: DË ° d ONLN d+ºA»q )…fillList ˇˇÿù DË ° d ONLN d3Ωq»¯ )0 messages, the Chooser sends ˇ˛¥º ° d ONLN dP… x‘ â (— xthe ˇ˝ix 4º ° d ONLN dT» ä‘ ∫ )fillList ˇ˛¥º 4º ° d ONLN d\… ∫‘® )04 message to the device package. The device package r a∏ ° d ONLN dê…®‘‡ )Ó esponds by fi À0 ° d ONLN dù…‡‘˜ )8lling . ° d ONLN d£’ x‡ Û (› x the device list with the appr ’ ° d ONLN d¿’ Û‡V ){opriate device choices. ° d ONLN dŸÁ nÚ u (Ô n6. ° d ONLN d‹Á xÚ ~ )
T µ¿ ° d ONLN d›Á }ÚÒ )Wo determine which entries in the device list should be selected, the Chooser calls the . ° d ONLN d4Û x˛ Ô (˚ xdevice package with the ° d ONLN dLÚ Ô˛ )wgetSel ° d ONLN dRÛ˛§ )$ message. The device package r R` ° d ONLN dpÛ§˛ÿ )ë esponds by . ° d ONLN d{ˇ x
¿ ( xNinspecting the list and setting the selected or unselected state of each entry èÄ ° d ONLN d…ˇø
◊ (ø. The . ° d ONLN dœ x · ( xChooser may send the ° d ONLN d‰
· )igetSel ° d ONLN dÍ 8 )$ message fr R` ° d ONLN dı 8Ò )3'equently; for example, each time a new . ° d ONLN d x" { ( xr E ° d ONLN d |" Ω )esponse to the R ° d ONLN d , Ω" fi )AAppleT ` ° d ONLN d 2 fi" )!alk zone interr
¿ ° d ONLN d A "Ô )@/ogation arrives. The Chooser does not send the . ° d ONLN d p" x. ú (+ xgetSel ° d ONLN d v# ú.ô )$9 message for serial printers; it highlights the icon corr R` ° d ONLN d Ø#ô.Ë )˝esponding to the . ° d ONLN d ¿/ x: ä (7 xcurr Ø ° d ONLN d ƒ/ ä: ) ently-selected serial port, as r ° ° d ONLN d ‰/ : )Åecor ` ° d ONLN d Ë/ :u )ded in low memory R@ ° d ONLN d ˘/t:v )V. ° d ONLN d ¸A nL u (I n7. ° d ONLN d ˇA xLˆ )
YIf the device package allows multiple devices to be active at once, the Chooser sets the ° d ONLN d
XM xX å * appr I@ ° d ONLN d
\M çX“ )Lopriate List Manager bits. When the user selects or deselects a device, the ° d ONLN d
®Y xdG (a x.Chooser calls the device package with the appr )‡ ° d ONLN d
÷YHdÚ )–&opriate message. For packages that do . ° d ONLN d
† ° d ONLN d ≥} ¯à3 )Äopriate, and r õ` ° d ONLN d ¡}3àE );ecor ¿ ° d ONLN d ≈}Fàó )ds the user choice. ° d ONLN d ⁄è nö u (ó n8. ° d ONLN d ›è xö Û )
When the user chooses a dif ‰¿ ° d ONLN d ¯è Ûö ˇ ){fer «@ ° d ONLN d ˚è ˇö¢ ) %ent device type or closes the Chooser V@ ° d ONLN d è¢öÙ )£, the Chooser calls ˇ˛¥º . ° d ONLN d 4õ x¶ ö (£ xthe curr ° d ONLN d <õ õ¶ )# ent device package with the ˇ˝ix é» ° d ONLN d Xö ¶R )Å terminate ˇ˛¥º é» ° d ONLN d aõR¶˜ )6& message, if the package accepts this . ° d ONLN d áß x≤ ƒ (Ø xkind of message. ¿ ° d ONLN d òß ƒ≤§ )L4At this time, the package can clean up, if necessary ≤` ° d ONLN d Ãߣ≤‚ )fl. The Chooser ˇÊ @ ˇ ˇˇˇˇ @
UpdateResFile ˇˇ4 ≠ú ° d ONLN d ]% h1 )N pr è0 ° d ONLN d ]1 hN ) ocedur aê ° d ONLN d % ]N h™ ) e, closes the device r p¿ ° d ONLN d ; ]™ h¡ )\esour C ° d ONLN d @ ]¡ h” )ce fi RT ° d ONLN d E ]” h˚ ) le, and fl pº ° d ONLN d O ]˚ h )(ushes . ° d ONLN d U i ñ t ( q ñthe system startup volume.
ô H ü 4 ö H ü ö ä ö
ˇ·ˇ‚7^
ˇˇ◊ ˇ◊ ° d ONLN d p â ä ô ö ( ï äCr îø ° d ONLN d r â õ ôt ) eating a Chooser Extension File ˇˇˇˇˇˇ • ( ï2
° d ONLN d ˆ æ ä … Æ * File type ° d ONLN d æ Ó … )d Device type
. ° d ONLN d à ä ÿ Æ ( ’ ä'PRES' . ° d ONLN d Õ Ó ÿ' )dSerial printer . ° d ONLN d& ◊ ä „ Æ ( ‡ ä'PRER' . ° d ONLN d- ÿ Ó „= )dNon-serial printer . ° d ONLN dA ‚ ä Ó Æ ( Î ä'RDEV' . ° d ONLN dH „ Ó Ó& )d Other device ° d ONLN dU Ó H ˘ J ( ˆ H ° d ONLN dZ ä ê +BY @Ä ° d ONLN d[ ê Í )ou can specify the cr U¿ ° d ONLN dp Í H )Zeator of your device r Ä ° d ONLN dÜ I a )_esour L¿ ° d ONLN dã a r )ce fi ` ° d ONLN dê s )"le, which allows you to give your ° d ONLN d≤ ä · ( ädevice its own icon. ° d ONLN d« ä) ê *Y @Ä ° d ONLN d» ê) )ou can include these r ¶† ° d ONLN dfi ) )`esour Ó‡ ° d ONLN d„ )Ü ) ces in your device package fi ≤¿ ° d ONLN d á)ë )le:
° d ONLN d1 ä; ∑ (8 ä
Resource T @– ° d ONLN d1 ∑; ‰ )-
ype and ID ° d ONLN d1;8 )Q Description
. ° d ONLN d)> äJ Æ (G ä'PACK' . ° d ONLN d0? ¥J Õ )*–4096 ° d ONLN d6?Jk )TDevice package. This r ° d ONLN dL?lJÑ )desour N` ° d ONLN dQ?ÑJ‰ )ce contains the device ° d ONLN dkKVz (Spackage header and code. . ° d ONLN dÖ\ äh Æ (e ä'STR ' . ° d ONLN då] ¥h Õ )*–4096 ° d ONLN dí]h )TT ∫¿ ° d ONLN dì]
hJ )
ype name for b@ ° d ONLN d†]Jhk )=AppleT Ä ° d ONLN d¶]khÌ )! alk devices. The Chooser sear K‡ ° d ONLN d√]Ìh )Çches ° d ONLN dÃit* (qthe curr ` ° d ONLN d‘i+t; )#ent ` ° d ONLN dÿi;tË )(Appletalk zone for devices of this type. . ° d ONLN dz äÜ Æ (É ä'GNRL' . ° d ONLN d { ¥Ü Õ )*–4096 ° d ONLN d{Üâ )T Appletalk information. The fi ;@ ° d ONLN d,{äÜœ )Çrst byte of this r óÄ ° d ONLN d>{œÜÁ )Eesour fl¿ ° d ONLN dC{ÁÜ )ce ° d ONLN dIáíç (è contains the Name-Binding Pr ¿ ° d ONLN deáéíÕ )Üotocol (NBP) r Û@ ° d ONLN dsáÃí )>etry interval, ° d ONLN dÇì Hû J (õ H ° d ONLN dÜìû« )¿+the second byte contains the timeout count. . ° d ONLN d≥§ ä∞ Æ (≠ ä'STR ' . ° d ONLN d∫• ¥∞ Õ )*–4091 ° d ONLN d¿•∞ )T<List box label. The Chooser labels the device list with this ° d ONLN d ±º„ * 5string after the user has selected the device’s icon. . ° d ONLN d7¬ äŒ Æ (À ä'STR ' . ° d ONLN d>√ ¥Œ Õ )*–4087 ° d ONLN dD√Œ\ )TRadio button label. . ° d ONLN dY‘ ä‡ Æ (› ä'STR ' . ° d ONLN d`’ ¥‡ Õ )*–4088 ° d ONLN df’‡ )TOf Ç ° d ONLN dh’‡f ) f radio button title. . ° d ONLN dÊ äÚ Æ (Ô ä'STR ' . ° d ONLN dÜÁ ¥Ú Õ )*–4089 ° d ONLN dåÁÚe )TOn radio button title. . ° d ONLN d§¯ ä Æ ( ä'STR ' . ° d ONLN d´˘ ¥ Õ )*–4092 ° d ONLN d±˘V )TRight button title. . ° d ONLN dΔ
ocedur fi` ° d ONLN dX;0Fı ) -e to modify the device list—to include pictur ‡ ° d ONLN dÖ;ˆFˇ )Δes ° d ONLN dàG HR J (O H ° d ONLN dåGRf )¿or icons, for example. . ° d ONLN d§X äd Æ (a ä'STR ' . ° d ONLN d´Y ¥d Õ )*–4090 ° d ONLN d±Ydó )T Reserved for use by the Chooser …† ° d ONLN d–Yñdò )é. ˇˇ—z . ° d ONLN d“q ä| ë (y äY ï ° d ONLN d”q ê| )ou should also include a ˇˇ¢Ù ¨b ° d ONLN dÏp|% )q'BNDL' ˇˇ—z ¨b ° d ONLN dÚq%|+ )$ r P< ° d ONLN dÙq,|C )esour "ú ° d ONLN d˘qC| )0ce to give your device type a distinctive icon, . ° d ONLN d)} äà` (Ö ä0because this may be the only way that devices ar D† ° d ONLN dY}aàà )◊ e identifi d‡ ° d ONLN dc}àà˝ )'ed in the Chooser window º ° d ONLN d{}¸à )t. The . ° d ONLN dÅâ äî= (ë ä'Finder Interface chapter describes the ° d ONLN d®à=îa )≥'BNDL' ° d ONLN dÆâaîh )$ r R` ° d ONLN d∞âhî )esour $¿ ° d ONLN dµâîã )ce. . ° d ONLN dπõ ä¶ ÷ (£ äThe next section, *@ ° d ONLN dÀõ ◊¶ Á )M“Cr @ ° d ONLN dŒõ Á¶Y )eating a Device Package,” @ ° d ONLN dÁõY¶· )r discusses the device package r o‡ ° d ONLN dõ·¶˘ )àesour ∏ ° d ONLN d õ˘¶ )ce in ° d ONLN dß ä≤ ú (Ø ämor éÄ ° d ONLN dß ú≤ )e detail, and the section † ° d ONLN d.ß≤f )k“How the Chooser W `Ä ° d ONLN d@ße≤≠ )^orks” on page 2-
` ° d ONLN dPßÆ≤∏ )I21
` ° d ONLN dRß∏≤ )
describes how the ° d ONLN de≥ äæ › (ª äChooser uses the fi Ä ° d ONLN dx≥ fiæ ˆ )Telds r Q@ ° d ONLN d~≥ ˆæ )
elated to ÑÄ ° d ONLN dà≥ æ? )(AppleT 7¿ ° d ONLN dé≥?æN )!alk. ˇÑ @ ˇ ˇˇˇˇ @
° d ONLN d ] l hÙ ( e lVThe Chooser window allows your device package to display two buttons, called the Left ° d ONLN d V i l tfi * Vbutton and the Right button because of their default positions. The left button has a ° d ONLN d ¨ u l Ä ú *
double bor î ° d ONLN d ∂ u ú Äfi )0Kder and is highlighted (the title string is dark, not gray) when one or mor xÄ ° d ONLN d ufi ÄÂ ( }fie ° d ONLN d Å l å ò ( â l
devices ar ؇ ° d ONLN d
Å ò å Ã ),
e selected fr „ ° d ONLN d Å Ã å∫ )47om the device list. When this button is highlighted, pr ÁÄ ° d ONLN dQ Å∫ åÿ )Óessing ° d ONLN dX ç l ò ∞ ( ï lReturn or Enter õ† ° d ONLN dg ç ∞ ò[ )D*, or double-clicking in the device list ar
° d ONLN dë ç\ ò˜ )¨%e equivalent to clicking the button. ° d ONLN d∂ ô l § ˚ ( ° l!The right button has a single bor ` ° d ONLN d◊ ô ¸ §Ù )ê9der and is always highlighted, and the user can activate ° d ONLN d • l ∞ Δ ( ≠ lit only by clicking it. ° d ONLN d( ∑ l ¬‹ *SThe Chooser also allows you to display two radio buttons and a radio button label. ° d ONLN d{ √ l Œ µ * These buttons ar û¿ ° d ONLN dã √ µ Œb )I'e called the On radio button and the Of ¨† ° d ONLN d≤ √b ŒÈ )≠ f radio button because those ar k@ ° d ONLN d— √Í ŒÒ )àe ° d ONLN d” œ l ⁄ Δ ( ◊ lthe titles the LaserW nÄ ° d ONLN dË œ Δ ⁄… )Z;riter uses, but you can give them whatever titles you want. . ° d ONLN d$ · l Ï s ( È lY ï ° d ONLN d% · r Ï@ ).ou can position these buttons by including a r g` ° d ONLN dS ·@ ÏW )Œesour 9¿ ° d ONLN dX ·W Ïá ) ce of type ,
Courier 9¿ ° d ONLN dc ‡á Ï´ )0'ncrt' 9¿ ° d ONLN di ·´ ÏÒ )$ with an ID of 9¿ ° d ONLN dx ·Ò ψ )F– . ° d ONLN dy Ì l ¯ û ( ı l 4096. The fi »Ä ° d ONLN dÖ Ì û ¯ Ω )2rst wor L ° d ONLN då Ì æ ¯ ) d in this type of r @ ° d ONLN dü Ì
¯" )Lesour NÄ ° d ONLN d§ Ì" ¯J ) ce specifi vÄ ° d ONLN dÆ ÌJ ¯ö )(es the number of r Ÿ@ ° d ONLN d¿ Ìö ¯Î )Pectangles, and the ° d ONLN d” ˘ l o ( lr E ° d ONLN d‘ ˘ p û ) est of the r y¿ ° d ONLN d‡ ˘ û ∂ ).esour ¬ ° d ONLN d ˘ ∂ ˝ )ce contains the r Ä ° d ONLN dˆ ˘ ˛6 )H ectangle defi ` ° d ONLN d ˘6r )8nitions. The fi ¿@ ° d ONLN d ˘rÉ )<rst r w@ ° d ONLN d ˘Ñ˜ ) ectangle positions the left ° d ONLN d3 lU (
l7button, the second positions the right button, the thir 1 ° d ONLN djVÊ )Í!d positions the On radio button, ° d ONLN dã l Ù ( l and the fourth positions the Of ÃÄ ° d ONLN d™ Ù O )àf radio button. The fi /Ä ° d ONLN d¿P b )\fth r ‹ ° d ONLN d≈b fi ) ectangle positions the radio ° d ONLN d‚ l( £ (% l
button label. ° d ONLN d/ l: á *Each r "` ° d ONLN dˆ/ à: ¿ ) ectangle defi #@ ° d ONLN d/ ¿:m )8)nition is 8 bytes long and contains the r ‡ ° d ONLN d,/m:ß )≠
ectangle coor @‡ ° d ONLN d9/ß: ):dinates in the ° d ONLN dH; lF u (C lor ∫Ä ° d ONLN dJ; uFP ) 5der [top, left, bottom, right]. The default values ar ° d ONLN d;QF` )‹e [1 ‡ ° d ONLN dÉ;`F‹ ) 12, 206, 132, 266] for the left ° d ONLN d£G lR ß (O l
ˇˇ◊ ˇ◊ ° d ONLN dfl¡ l— | (Õ lCr îø ° d ONLN d·¡ }—# )eating a Device Package ˇˇˇˇˇˇ • (Õ2
° d ONLN d˘ÿ l„ ´ (‡ lLike a driver r { ° d ONLN dÿ ´„ √ )?esour √` ° d ONLN d
ÿ √„\ )#ce, a device package has two parts: ,
Zapf Dingbats
° d ONLN d1Ï lÛ q (Ú ln
° d ONLN d3Í xı+ ) 'the package header that contains some fl Õ‡ ° d ONLN d[Í+ı‡ )≥(ags and some other data about the driver
° d ONLN dÑ˛ l q ( ln
° d ONLN dḠx fi ) the package code that r ù‡ ° d ONLN dû¸ fia )fesponds to Chooser messages ° d ONLN d∫ l ( l%The package header contains a few wor ˇ@ ° d ONLN dfl8 )Æds of fl . ° d ONLN dÁ9… ) ags and other data and a branch ° d ONLN d l% Ä (" linstr ó¿ ° d ONLN d Ä% ) uction to the package’s Device r ‡ ° d ONLN d ,
%. )çoutine. K@ ° d ONLN d 4.%F )!Figur ° d ONLN d 9F%Z )e 2-3 ªÄ ° d ONLN d >Z% ) shows the format of a package ° d ONLN d ]& l1 ä (. lheader 5† ° d ONLN d c& ä1 å ) . ˇ,ä @ ˇ ˇˇˇˇ @
Courier ° d ONLN d ≠¨ú∏∫ )∂BRA.S ° d ONLN d ≤≠∫∏“ ) instr l ° d ONLN d ∏≠“∏ )uction to the . ° d ONLN d Δπ äƒ » (¡ ä
package code. ° d ONLN d ‘À ä÷6 *(The device ID is an integer that identifi ∫ ° d ONLN d ˝À6÷ª )¨ es the device. The version wor g‡ ° d ONLN dÀº÷– )Üd dif . ° d ONLN d À—÷› )fer Ä ° d ONLN d#À›÷ ) entiates ° d ONLN d,◊ ä‚ (fl ä versions of the driver code. ° d ONLN dIÈ äÙ≈ *DThe package code should implement the Package function. The section É¿ ° d ONLN dçÈ≈ÙÚ (Ò≈ “How the ° d ONLN dñı ä ª (˝ ä Chooser W ·† ° d ONLN düı ∫ )0orks” on page 2- ãÄ ° d ONLN dØı
)I21 ãÄ ° d ONLN d±ı
˙ )
: gives the interface for this function. The next section, ° d ONLN dÎ ä ( ä“Responding to the Chooser ¿ ° d ONLN d )},” Ü¿ ° d ONLN d )* discusses how to implement this function. ° d ONLN d2 ä £ ( äThe fl »Ä ° d ONLN d8 £ ∫ )ags fi !` ° d ONLN d> ª · )Beld contains information about the device and the device package. ø@ ° d ONLN dÄ· Á (·T ı ° d ONLN dÅÊ )able 2-2 Ä ° d ONLN dâ )# ° d ONLN dä ä*) (' ä&lists the meaning of each bit of the fl ‹‡ ° d ONLN d± )*G )üag wor }Ä ° d ONLN d∑ H*P ) d.
w äà 4 w äà
w äà® 4 v â w ä ò ( W5 W5 w ä–® Ÿ Ÿ =Ä˙ `˙ ¿Ô f˘ ``˙ `Ô aˇ˙ {w‡˙ ~˛ÁÚ =øÄ˚ cˇ`˙ fi˚ø¯Ú Ï˙ c«`˙ €∑¿Ú }ˇÄ˚ c‡˙ fiÔxÚ Î Î Ÿ Ÿ Ÿ
° d ONLN dˇˇ ( d l Table 2-2 ° d ONLN d \ ™ g Ò )>Device package fl Ñê ° d ONLN d \ Ò g ˇ )Gags ° d ONLN d u l w ( | lBit ° d ONLN d u Æ “ )BMeaning
° d ONLN d # É l é v ( ã l31 ° d ONLN d & É Æ é ” )B
Set if an ˚ ° d ONLN d 0 É ” é Ù )%AppleT Æ@ ° d ONLN d 6 É Ù é )!
alk device ° d ONLN d B ê l õ Ö ( ò l30–29 ° d ONLN d H ê Æ õ )BReserved (clear to 0) ° d ONLN d _ ù l ® v ( • l28 ° d ONLN d b ù Æ ®ø )B?Set if the device package can have multiple instances selected ‰¿ ° d ONLN d ¢ ùø ®fi ( •øat once ° d ONLN d ´ ™ l µ v ( ≤ l27 ° d ONLN d Æ ™ Æ µt )B.Set if the device package uses the Left button ° d ONLN d fi ∑ l ¬ v ( ø l26 ° d ONLN d · ∑ Æ ¬{ )B/Set if the device package uses the Right button ° d ONLN d ƒ l œ v ( à l25 ° d ONLN d ƒ Æ œI )B"Set if no zone name has been saved ° d ONLN d9 — l ‹ v ( Ÿ l24 ° d ONLN d< — Æ ‹s )B,Set if device package uses actual zone names ° d ONLN dj fi l È Ö ( Ê l23–21 ° d ONLN dp fi Æ È )BReserved (clear to 0) ° d ONLN dá Î l ˆ v ( Û l20 ° d ONLN dä Î Æ ˆ: )B Set if device uses the On and Of ˙Ä ° d ONLN d™ Î: ˆ‡ )å&f radio buttons and radio button label ° d ONLN d“ ¯ l Ö ( l19–17 ° d ONLN dÿ ¯ Æ )BReserved (clear to 0) ° d ONLN dÔ l v (
l17 . ° d ONLN dÚ ÆL )B"Set if device package accepts the ,
Courier ° d ONLN dLd )ûinit ° d ONLN ddå ) message . ° d ONLN d" l v ( l16 . ° d ONLN d% Æ L )B"Set if device package accepts the ° d ONLN dGL p )ûnewSel ° d ONLN dMp ò )$ message . ° d ONLN dW l* v (' l15 . ° d ONLN dZ Æ*L )B"Set if device package accepts the ° d ONLN d| L*| )ûfillList ° d ONLN dÑ |*§ )0 message . ° d ONLN dé, l7 v (4 l14 . ° d ONLN dë, Æ7L )B"Set if device package accepts the ° d ONLN d≥+L7p )ûgetSel ° d ONLN dπ,p7ò )$ message . ° d ONLN d√9 lD v (A l13 . ° d ONLN dΔ9 ÆDL )B"Set if device package accepts the ° d ONLN dË8LDp )ûselect ° d ONLN dÓ9pDò )$ message . ° d ONLN d¯F lQ v (N l12 . ° d ONLN d˚F ÆQL )B"Set if device package accepts the ° d ONLN d ELQ| )ûdeselect ° d ONLN d%F|Q§ )0 message . ° d ONLN d/S l^ q ([ l1 Û` ° d ONLN d0S p^ u )1 . ° d ONLN d2S Æ^L )>"Set if device package accepts the ° d ONLN dTRL^Ç )û terminate ° d ONLN d]SÇ^™ )6 message . ° d ONLN dg` lk Ä (h l10–0 ° d ONLN dl` Æk )BReserved (clear to 0)
û *§¯ 4ü *§¯ ü lü¯
ˇ·ˇ‚7^
ˇˇ◊ ˇ◊ ° d ONLN dÑé lû, (ö lResponding to the Chooser ˇˇˇˇˇˇ • (ö2
° d ONLN dü• l∞ Œ (≠ lThis section gives mor 2‡ ° d ONLN dµ• œ∞™ )c0e details about how your device package should r q ° d ONLN d•™∞ )€espond when it ° d ONLN dÙ± lº o (π lr E ° d ONLN dı± pº » )eceives a message fr Á ° d ONLN d ± »º
)Xom the Chooser ° d ONLN d±º )F. ° d ONLN d√ lŒ÷ (À lMWhen the Chooser sends your device package a message, the Chooser extension fi ∞† ° d ONLN dg√÷ŒÈ (À÷le is ° d ONLN dmœ l⁄ é (◊ lthe curr ` ° d ONLN duœ è⁄ £ )#ent r .¿ ° d ONLN dzœ £⁄ ª )esour w ° d ONLN dœ ª⁄ à )ce fi =† ° d ONLN dÑœ Õ⁄e )"le, the Chooser window is the curr D` ° d ONLN d¶œe⁄ )ò ent grafPort, and the System ° d ONLN d√€ lÊ π („ lFolder of the curr ö¿ ° d ONLN d’€ πÊc )M(ent startup disk is the default volume. Ô ° d ONLN d˝€cÊi )™Y ؆ ° d ONLN d˛€iÊŸ )our device package must ° d ONLN dÁ lÚ u (Ô lpr G ° d ONLN dÁ vÚ Δ )
eserve all of these. ° d ONLN d-˘ l r ( lT µ¿ ° d ONLN d.˘ q ì )able 2-3 √@ ° d ONLN d6˘ ìö )"9 lists the Chooser messages and how your package should r flÄ ° d ONLN do˘ö„ (öespond to them. ˇ @ ˇ ˇˇˇˇ @
° d ONLN dˇˇ ( d ä Table 2-3 ° d ONLN d \ » gd )>#Chooser messages and their meanings ° d ONLN d % t ä ∞ ( | äMessage ° d ONLN d - t Ó )dMeaning ,
Courier
. ° d ONLN d 6 Ç â é ° ( ã âinit . ° d ONLN d ; É Ó é )e=The Chooser sends this message to your package when the user ° d ONLN d x ë Ó ú6 *selects the icon r Í ° d ONLN d ä ë6 úD )Hepr z‡ ° d ONLN d ç ëE ú ),esenting your package in the icon list. The . ° d ONLN d π û Ó ™ ( ß ÓobjName ° d ONLN d ¿ ü ™› )*+ parameter contains a pointer to a data str l ° d ONLN d Î ü› ™Û )≈uctur >` ° d ONLN d üÛ ™ )e that . ° d ONLN d ˜ ≠ Ó ∏B ( µ Ócontains a size wor p¿ ° d ONLN d
≠B ∏· )T#d followed by four handles to Contr } ° d ONLN d- ≠· ∏ )üolRecor ˝@ ° d ONLN d4 ≠ ∏
" ûf ° d ONLN dÿãÕ )ù SetCtlValue ˇˇ ûf ° d ONLN d„Õ” )B r u◊ ° d ONLN d” )outine. See the ° d ONLN dı Ó(H (% Óchapter “The Contr R` ° d ONLN d H(• )Zol Manager” for mor $¿ ° d ONLN d •(˛ )]e information. The $¿ ° d ONLN d- ˛(
)Yp2 $¿ ° d ONLN d/
(
) . ° d ONLN d0+ Ó6P (3 Óparameter is not used. . ° d ONLN dH> âJ ≠ (G ânewSel . ° d ONLN dO? ÓJ )e?If your device package allows multiple selections, the Chooser ° d ONLN déM ÓX *=sends this message to your packages when the user changes or . ° d ONLN dÀ[ ÓfS *adds a selection. The ° d ONLN d·ZSf} )eobjName ° d ONLN dË[}fî )* and ° d ONLN dÌZîf† )p2 ° d ONLN dÔ[†f‰ ) parameters ar R` ° d ONLN d˝[‰f )D e not used. ° d ONLN d
n âz π (w âfillList . ° d ONLN do Óz )e>The Chooser sends this message when the user selects a device ˇˇj® . ° d ONLN dQ} Óà *
icon. The ˇ˛’P UP ° d ONLN d[|à& ),p1 ˇˇj® UP ° d ONLN d]}&à ) 5 parameter contains a handle to a List Manager list. . ° d ONLN díã Óñ Ù (ì ÓY @Ä ° d ONLN dìã Ùñ› )3our device package should use the List Manager to fi å@ ° d ONLN d«ã›ñ )È
ll this list . ° d ONLN d‘ô Ó§∫ (° Ó,with choices for the particular device. The ° d ONLN d ò∫§‰ )ÃobjName ° d ONLN dô‰§˚ )* and ° d ONLN d ò˚§ )p2 ° d ONLN dô§
) . ° d ONLN dß Ó≤+ (Ø Ó
parameters ar ì ° d ONLN d ß+≤Z )= e not used. ° d ONLN d)ª âΔ £ (√ âgetSel ° d ONLN d0ª ÓΔ˜ )e:The Chooser sends this message to determine which entries ° d ONLN dj… Ó‘
*Ashould be selected. The p1 parameter contains a handle to a List ° d ONLN d´◊ Ó‚* *Manager list. ¥Ä ° d ONLN dπ◊*‚0 )<Y u ° d ONLN d∫◊0‚¨ )our device package should r @Ä ° d ONLN d’◊≠‚
)}espond by inspecting ° d ONLN dÍÂ Ó (Ì ÓCthe list and setting the selected or unselected state of each entry QÄ ° d ONLN d-Â
(Ì, ˇˇ . ° d ONLN d/Û Ó˛ (˚ Ó
using the ˇ˛8 ∏ ° d ONLN d9Ú˛U )+
LSetSelect ˇˇ ∏ ° d ONLN dCÛU˛Ä )< function. ¬ú ° d ONLN dNÛIJá )+Y ◊ú ° d ONLN dOÛܲ )!ou should alter only the entries . ° d ONLN dp Ó ( Óthat r ° d ONLN dv )equir 2` ° d ONLN d{ )7e updating. The Chooser does not send this message for ° d ONLN d≤ Ó0 ( Óserial printers. ° d ONLN d≈# â. ° (+ âselect ° d ONLN dÃ# Ó. )e?If your device package does not allow multiple selections, the ° d ONLN d 1 Ó<˙ *:Chooser sends this message to your packages when the user ° d ONLN dE? ÓJ; *selects a device fr o ° d ONLN dX?;Jç )Mom the device list. Ê@ ° d ONLN dl?çJì )RY ¶¿ ° d ONLN dm?ìJ≈ ) ou should r wÄ ° d ONLN dx?ΔJÿ )3ecor · ° d ONLN d|?ÿJ )
d the user ¢¿ ° d ONLN dÜ?J )-’s ° d ONLN dâM ÓX# (U Ó
selection, pr ·† ° d ONLN dñM#XΔ )5$eferably in your Chooser extension fi ‡ ° d ONLN dªM«X” )§le. å@ ° d ONLN døM”XŸ ) Y L¿ ° d ONLN d¿MŸX
) our device ° d ONLN dÀ[ Óf™ (c Ó*package may not call the List Manager in r y@ ° d ONLN dı[™f )ºesponse to this message. . ° d ONLN do Óz] (w ÓIf your package accepts ° d ONLN d(n]zç )ofillList ° d ONLN d0oçz“ )0 messages, the ° d ONLN d?n“z¸ )EobjName ° d ONLN dFo¸zˇ )* ° d ONLN dG} ÓàH (Ö Óparameter is undefi ° d ONLN dZ}HàÇ )Z ned and the ° d ONLN df|Çàé ):p2 ° d ONLN dh}éàˆ ) parameter gives the r R` ° d ONLN d~}ˆà )how . ° d ONLN dÅã Óñt (ì Ó number of the selected device. . ° d ONLN d¢ü әŠ* If your package does not accept ° d ONLN d¬ûÅ™± )ìfillList ° d ONLN d ü±™ˆ )0 messages, the ° d ONLN dŸ¨ Ó∏ (µ ÓobjName ° d ONLN d‡≠∏ )*6 parameter contains a pointer to a string of up to 32 ˇL @ ˇ ˇˇˇˇ @
er bits fr ≠‡ ° d ONLN d∂‰Ù )%om ° d ONLN dπ – ß ( –/the mouse up event. See the chapters “The Contr €‡ ° d ONLN dËß Ù )◊ol Manager” and ° d ONLN d¯ –*T (' –“The Event Manager” for mor 7† ° d ONLN d U*ì )Öe information.
Q *W¯ 4R *W¯ R lR¯
ˇ·ˇ‚7^
ˇˇ◊ ˇ◊ ° d ONLN d"A lQ (M lAllocating private storage ˇˇˇˇˇˇ • (M2
° d ONLN d=X lct (` l<Device packages initially have no data space allocated. Ther —† ° d ONLN dyXtcÑ (`te ar ‡@ ° d ONLN d}XÑcˆ )e two ways your package ° d ONLN dïd lo ô (l l
can acquir ˇÄ ° d ONLN düd ôo — )-
e data space: ,
Zapf Dingbats
° d ONLN d≠x l q (~ ln
° d ONLN dØv xÅì ) AUse the List Manager to allocate extra memory in the device list.
° d ONLN dÒä lë q (ê ln
° d ONLN dÛà xì É ) Cr \ ° d ONLN dıà Éì ¢ ) eate a r ˆ† ° d ONLN d˝à ¢ì ∫ ) esour >‡ ° d ONLN dà ªì Δ )ce. ° d ONLN dö l•N (¢ l4The Chooser uses column 0 of the device list to stor ‰@ ° d ONLN d:öN•Û )‚'e the names displayed in the list box; ˇˇ2⁄ . ° d ONLN da¶ l± (Æ l'for device packages that do not accept ˇ˛e¥ „ˆ ° d ONLN dà•±K )ØfillList ˇˇ2⁄ „ˆ ° d ONLN dê¶K±fi )0# messages, it uses column 1 to stor L ° d ONLN d≥¶fl±¯ )îe the . ° d ONLN dπ≤ lΩ â (∫ l4-byte @ ° d ONLN d¿≤ äΩ ´ ) AppleT ÀÄ ° d ONLN dΔ≤ ™Ω Ù ) alk internet addr ’@ ° d ONLN d◊≤ ÙΩé )J&esses of the devices in the list. Ther ° d ONLN d˝≤èΩ† )õefor q ° d ONLN d ≤†Ω‡ )e, your device ˇ!< @ ˇ ˇˇˇˇ @
. ° d ONLN d ] ä hu ( e ä3package can use column 1 and higher (if it accepts ,
Courier ° d ONLN d 3 \u h• )ÎfillList ° d ONLN d ; ]• h )0 messages) or column 2 . ° d ONLN d R i ä t ÿ ( q äand higher to stor 5` ° d ONLN d d i Ÿ t )Oe private data. æ‡ ° d ONLN d t i t )AY ` ° d ONLN d u i tr )ou can use standar ¸‡ ° d ONLN d á ir tª )Rd List Manager r s ° d ONLN d ó iº t˝ )Joutines to add ° d ONLN d ¶ u ä Ä fl ( } äthese columns, stor UÄ ° d ONLN d π u fl Ä: )Ue data in them, and r öÄ ° d ONLN d Œ u: Äë )[etrieve the data stor 0` ° d ONLN d „ uí ı )Xed ther 8 ° d ONLN d Í u± Ä∫ ) e. ‘ ° d ONLN d Ì u∫ Ä¿ ) Y î† ° d ONLN d Ó u¿ ÄÒ ) our device . ° d ONLN d ˘ Å ä å ˇ ( â äpackage can also use the ° d ONLN d Ä ˇ å# )urefCon ° d ONLN d Å# å- )$ fi ° d ONLN d Å- å )
,eld of the device list for its own purposes. . ° d ONLN dH ì ä û ( õ äZUsing the device list is limited by the fact that the Chooser disposes of the device list ° d ONLN d¢ ü ä ™í * :whenever the user changes device types or changes the curr ` ° d ONLN d‹ üì ™Ê ( ßìent zone. However ‡ ° d ONLN dÌ üÊ ™˚ )S, the ˇˇ>ï . ° d ONLN dÛ ´ ä ∂e ( ≥ ä/Chooser does call your device package with the ˇ˛}* t® ° d ONLN d" ™f ∂ú )‹ terminate ˇˇ>ï t® ° d ONLN d+ ´ú ∂‹ )6 message befor ƒ2 ° d ONLN d9 ´‹ ∂ )@e it disposes . ° d ONLN dG ∑ ä ¬ µ ( ø ä of the list. ° d ONLN dT … ä ‘V *.Also, if your device package does not accept fi ¡` ° d ONLN dÉ …V ‘ )Ã)llList messages, the Chooser disposes of ° d ONLN d¨ ’ ä ‡ ( › ä the device list whenever a new r ‡ ° d ONLN dà ’ ‡F )è
esponse fr Ò ° d ONLN d÷ ’E ‡f ),om the πÄ ° d ONLN d› ’f ‡á )!AppleT l¿ ° d ONLN d„ ’á ‡« )!alk zone interr r ° d ONLN dÚ ’« ‡ )@ogation arrives. ° d ONLN d · ä Ï ≥ ( È äHowever † ° d ONLN d
· ≥ ÏÕ ))?, the Chooser does call the getSel message immediately afterwar ∫@ ° d ONLN dI ·Õ ÏŸ ( ÈÕds. ° d ONLN dM Û ä ˛J ( ˚ ä,The second way to get storage space is to cr ö ° d ONLN dy ÛJ ˛i )¿eate a r 4¿ ° d ONLN dÅ Ûj ˛Ç ) esour } ° d ONLN dÜ ÛÇ ˛Ã )ce in the device r ¿‡ ° d ONLN dò Ûà ˛‰ )Jesour ° d ONLN dù Û ˛ˆ )ce fi œ¿ ° d ONLN d¢ Ûˆ ˛ )le. ° d ONLN d¶ ˇ ä
• ( äThis fi $@ ° d ONLN d≠ ˇ ¶
˛ ) le is always the curr Ä ° d ONLN d¬ ˇ ˛
)Xent r 5‡ ° d ONLN d« ˇ
* )esour ~ ° d ONLN dà ˇ*
; )ce fi D¿ ° d ONLN d— ˇ<
ˇ )+le when the Chooser sends a message to the . ° d ONLN d¸ ä ( ä package, so you can use the ° d ONLN d
M )Å GetResource ° d ONLN d# MT )B r R` ° d ONLN d% T ))outine to obtain a handle to the storage. . ° d ONLN dO ä(L (% ä-It is important for most device packages to r ‡ ° d ONLN d| M(_ )√ecor ~@ ° d ONLN dÄ _( )&d which devices the user has chosen. T à@ ° d ONLN d¶ ( )™o ° d ONLN d®) ä4 ¡ (1 ädo this, the r Ï¿ ° d ONLN d∂) ¡4A )7ecommended method is to cr 5` ° d ONLN d–)B4a )Åeate a r – ° d ONLN dÿ)a4y ) esour @ ° d ONLN d›)z4 )ce in your driver r (Ä ° d ONLN d) 4‚ )Pesour p¿ ° d ONLN dı)‚4Û )ce fi 7` ° d ONLN d˙)Ù4 )le. ° d ONLN d˛5 ä@ £ (= äThis r ‹Ä ° d ONLN d5 £@ ª )esour $¿ ° d ONLN d 5 º@¢ )7ce can be of any type; in fact, it’s advantageous to pr è ° d ONLN d@5¢@Ó )Êovide your own r Y¿ ° d ONLN dP5Ô@ )Mesour ¢ ° d ONLN dU5@ )ce ° d ONLN dXA äL Ò (I ätype so that no other pr ˘` ° d ONLN dpA ÒLÔ )g;ogram will try to modify it. If you choose to use a standar † ° d ONLN d´AL¯ )ˇd ° d ONLN d≠M äX ç (U är E ° d ONLN dÆM éX ¶ )esour ç@ ° d ONLN d≥M ¶X* ) ce type, you should use only r ` ° d ONLN d—M+XC )Öesour X† ° d ONLN d÷MCX¿ ) ce IDs in the range –4080 thr w‡ ° d ONLN dÛM¿XÙ )} ough –4065.
] Hx 4^ Hx
â Hë 4ä Hë ä Hä
ˇ·ˇ‚7^
ˇˇ£‰ ˇÆ ° d ONLN dˇv Hà X (Ñ HW œ ° d ONLN d v Xà ª )riting a Desk … ° d ONLN dv ªà
)c Accessory ˇˇˇˇˇˇ ⁄| (Ñ 2
° d ONLN dö ä• fi (¢ äDesk accessories ar @ ° d ONLN d+ö fl•˛ )UDe device drivers that act like small applications. Desk accessories ° d ONLN do¶ ä± Ω (Æ ä typically pr S@ ° d ONLN d{¶ Ω± )3Fovide a user interface with a window and a menu, perform some limited ° d ONLN d¡≤ äΩ – (∫ äfunction, and ar ¿` ° d ONLN d—≤ –Ω )F e opened fr ö‡ ° d ONLN d‹≤Ω# )2om the c` ° d ONLN d„≤#Ω )!0Apple menu. The Chooser is an example of a desk ° d ONLN dæ ä… ¥ (Δ ä accessory † ° d ONLN d æ ≥… µ )). ° d ONLN d – ä€ Ê (ÿ äDesk accessories wer 3‡ ° d ONLN d2– Á€Æ )]-e originally designed for the Macintosh envir 4‡ ° d ONLN d_–Æ€
° d ONLN d ] l h ¿ ( e lWhen events occur ° d ONLN d ] ¿ h( )T, the Event Manager dir `‡ ° d ONLN d ( ]( hÓ )h/ects them to the desk accessory by calling its ° d ONLN d W i l t Ö ( q lContr Â@ ° d ONLN d \ i Ö t ¡ )ol driver subr - ° d ONLN d j i ¬ tÔ )=Aoutine. The Event Manager handles switching between applications ° d ONLN d ´ u l ÄÔ ( } lWand the desk accessories in the system heap and passing along the events meant for the ° d ONLN d Å l å ≠ * desk accessory ± ° d ONLN d Å ¨ å: )@ . The desk accessory need only r ΩÄ ° d ONLN d0 Å: åí )éespond to the Contr £` ° d ONLN dC Åí å† )Xol r F@ ° d ONLN dG Å° å¿ )equest. ° d ONLN dO ì l û⁄ ( õ lRWhen the user closes the desk accessory (by closing its window or choosing Quit fr Ê¿ ° d ONLN d° ì⁄ ûÍ ( õ⁄om ° d ONLN d§ ü l ™fi ( ß lSits menu) or an application closes the desk accessory (by calling the Menu Manager . ° d ONLN d˜ ´ l ∂ p * r R` ° d ONLN d¯ ´ p ∂ è )outine ,
Courier R` ° d ONLN dˇ ™ è ∂ ◊ ) CloseDeskAcc R` ° d ONLN d ´ ◊ ∂Û )H>), the desk accessory disposes of its window (if any) and any . ° d ONLN dI ∑ l ¬ ß ( ø lother data str ņ ° d ONLN dW ∑ ß ¬ æ );uctur Ä ° d ONLN d\ ∑ ø ¬ )es associated with it. ° d ONLN ds … l ‘ Ë ( — l In a single-application envir a ° d ONLN dê … Ë ‘Z )|onment in system softwar · ° d ONLN d® …Z ‘” )r e version 6.0 or in multiple- ° d ONLN d≈ ’ l ‡ ∑ ( › lapplication envir •Ä ° d ONLN d÷ ’ ∑ ‡ Ú )K onment wher ‘¿ ° d ONLN d· ’ Ú ‡— );4e the desk accessory is opened in the application’s ° d ONLN d · l Ï‹ ( È lRpartition (for example, when the user holds the Option key while opening the desk ° d ONLN dg Ì l ¯ ü * accessory fr 4@ ° d ONLN ds Ì † ¯ ¡ )4om the ¸¿ ° d ONLN dz Ì ¿ ¯Û ) CApple menu), the Event Manager handles events for desk accessories ° d ONLN dΩ ˘ l Æ ( lin a slightly dif @ ° d ONLN dŒ ˘ Ø ª )Cfer Ó¿ ° d ONLN d— ˘ ∫ Ï )
ent manner ¡¿ ° d ONLN d€ ˘ Ï™ )2., although it still translates them into Contr ˚@ ° d ONLN d ˘™∏ )æol r û ° d ONLN d
˘π )
equests. See ° d ONLN d l (
l'the chapter “The Event Manager” in the § ° d ONLN dA ù )≥ Inside Macintosh: Macintosh T ˆÄ ° d ONLN d^úµ )}oolbox ØÄ ° d ONLN dd∂Î ) volume for ° d ONLN dp l ã ( ldetails. ° d ONLN dy# l. n *
S *Y¯ 4T *Y¯ T lT¯
ˇ·ˇ‚7^
ˇˇ◊ ˇ◊ ° d ONLN d{C lS | *$Cr îø ° d ONLN d}C }S )eating a Driver Resour Ô ° d ONLN dìCSu )úce for a Desk ä ° d ONLN d°CvSº )] Accessory ˇˇˇˇˇˇ • )z2
° d ONLN d´Z le r (b lT µ¿ ° d ONLN d¨Z qe Å )o cr ‡Ä ° d ONLN d∞Z Åe fi )eate a desk accessory Á@ ° d ONLN d≈Z ›e )\
, you must cr Ç¿ ° d ONLN d“Zei ):eate it as a driver r ^` ° d ONLN dÁZieÅ )Resour ¶† ° d ONLN dÏZÅefl )ce and include it in a ° d ONLN df lq o (n lr E ° d ONLN df pq à )esour ç@ ° d ONLN d f àq ô )ce fi S‡ ° d ONLN df öq Î )le, as described in W@ ° d ONLN d"f Îq ˚ )Q“Cr 3@ ° d ONLN d%f ˚q^ )eating a Driver Resour ˘ ° d ONLN d;f^qú )cce” on page 2- ®† ° d ONLN dIfùq¢ )?5 ®† ° d ONLN dJf¢q≠ ). T „` ° d ONLN dMf¨qœ )
ypically ` ° d ONLN dUfœqÁ )#, you ° d ONLN d[r l} | (z lstor 9‡ ° d ONLN d_r }} ) e your desk accessory driver r m ° d ONLN d}r} )Ñesour µ@ ° d ONLN dÇr}Å )ce in a desk accessory fi Ä ° d ONLN dõrÇ}Í )ile, which allows you to ˇˇ»å . ° d ONLN d≥~ lâ ò (Ü l
include a ˇˇë ° d ONLN dΩ} ôâ Ω )-'BNDL' ˇˇ»å ° d ONLN d√~ Ωâ √ )$ r ¨ ° d ONLN d≈~ √â ⁄ )esour ~d ° d ONLN d ~ ⁄â’ )9ce to give your desk accessory an icon, and the user stor Ó» ° d ONLN d~’☠)˚es your . ° d ONLN d ä lï µ (í ldesk accessory fi Y† ° d ONLN d ä ∂ï € )J
le in the ƒ` ° d ONLN d&ä €ïK )%Apple Menu Items folder ! ° d ONLN d=äKïP )p. ° d ONLN d@ú lß (§ l"In addition to the driver header fi ؆ ° d ONLN dcú ßΩ )î-elds important for all drivers, described in ÓÄ ° d ONLN dêúΩßÕ )Ω“Cr Ä ° d ONLN dìúÕßÚ ) eating a ° d ONLN dú® l≥ ™ (∞ l
. ° d ONLN dÔ∫ x≈ ç ) The ° d ONLN dÛπ ç≈ √ ) drvrEMask ° d ONLN d¸∫ √≈ Õ )6 fi ° d ONLN dˇ∫ Õ≈ )
eld. This fi ° d ONLN d ∫≈˜ )44eld contains an event masks specifying which events . ° d ONLN d?Δ x—´ (Œ xCyour desk accessory can handle. If your desk accessory has a window ó` ° d ONLN dÇΔ™—„ (Œ™
, you should ° d ONLN dè“ x› ø (⁄ xinclude keyboar ®‡ ° d ONLN dû“ ø›fi )G?d, activate, update, and mouse-down events, but you should not ° d ONLN d›fi xÈ· (Ê xNinclude mouse-up events. When an event occurs, the Event Manager checks this fi qÄ ° d ONLN d,fi‚ÈÚ (Ê‚eld ° d ONLN d0Í xı (Ú xWto determine whether the desk accessory can handle the type of event, and if so, calls ° d ONLN dሠx Ï * the desk accessory’s Contr ¿ ° d ONLN d°ˆ Ì )uol subr Ç` ° d ONLN d®ˆ ) 3outine. See the chapter “The Event Manager” in the ° d ONLN d€ x
ˆ (
x Inside Macintosh: Macintosh T “Ä ° d ONLN d¯ ı
)}oolbox ãÄ ° d ONLN d˛
2 ) for mor V ° d ONLN d 3
⁄ )$%e information about events and event ° d ONLN d + x ñ ( xmasks.
° d ONLN d 2" l) q (( ln
ˇˇ§í . ° d ONLN d 4 x+ å ) The ˇˇI$ $í ° d ONLN d 8 ç+ Ω )drvrMenu ˇˇ§í $í ° d ONLN d @ Ω+ Δ )0 fi …$ ° d ONLN d C Δ+ ˘ ) eld. This fi H ° d ONLN d O ˙+¯ )48eld contains the menu ID of your desk accessory’s menu, . ° d ONLN d á, x7Q (4 x5if it has one, or any one of its menus, if it has mor « ° d ONLN d º,Q7 )Ÿ&e than one. Otherwise, it contains 0. ° d ONLN d ‚8 xC‰ (@ xPThe menu ID for a desk accessory’s menu must be negative and must be distinct fr c ° d ONLN d
28‰CÙ (@‰om ° d ONLN d
5D xO% (L x'the menu ID for other desk accessories.
ßb xm (j x$accessories often need to perform pr o¿ ° d ONLN d
Àbm- )†edefi +Ä ° d ONLN d
–b.mó )ned actions periodically ’‡ ° d ONLN d
Ëbñmfi )h. For example, a ° d ONLN d
˘n xyÁ (v xSclock desk accessory may want to change the time it displays every second. If your . ° d ONLN d Lz xÖÉ * ;desk accessory needs to perform a periodic action, set the ° d ONLN d áyÉÖπ (ÇÉ dNeedTime ° d ONLN d êzπÖ√ )6 fl ° d ONLN d ìz√Öˆ )
ag and use . ° d ONLN d ûÜ xë æ (é xthe drvrDelay fi ¿ ° d ONLN d ÆÜ øëñ )G1eld to indicate how often the action should occur Ù‡ ° d ONLN d flÜïëŒ )÷. The section ° d ONLN d Ìí xù à (ö x“Cr \ ° d ONLN d í àù Î )eating a Driver Resour !‡ ° d ONLN d í Ïù ˙ )dce” [¿ ° d ONLN d í ˙ùG ) describes these fi »` ° d ONLN d íGùy )M elds in mor õ` ° d ONLN d 'íyùõ )2 e detail. ° d ONLN d 1§ lØ ê (¨ lOf the fi ô‡ ° d ONLN d :§ êØ ı )$ve possible driver subr á` ° d ONLN d Q§ ıØ‹ )e3outines, your desk accessory needs to implement thr A‡ ° d ONLN d ѧ›ØÎ )Ëee: ° d ONLN d à∞ lª ” (∏ lOpen, Close, and Contr F‡ ° d ONLN d û∞ ‘ª · )hol. w ° d ONLN d ¢∞ ·ª Á )
Y 7† ° d ONLN d £∞ Áª¢ )(ou can implement a Prime and Status subr †Ä ° d ONLN d À∞¢ªÏ )ªoutine if needed. ˇ p @ ˇ ˇˇˇˇ @
dCtlWindow ˇˇ±à π¿ ° d ONLN d# ¬‹ Õ )< fi kH ° d ONLN d& ¬Ê Õ )
eld of the . ° d ONLN d1 Œ ñ Ÿ à ( ÷ ñ device contr l` ° d ONLN d= Œ à Ÿ Ó )6ol entry ç† ° d ONLN dE Œ Ì Ÿ Ô )!.
° d ONLN dG ‚ ä È è ( Ë än
° d ONLN dI ‡ ñ Îù ) ;Allocate private storage as you would for any device driver ‡ ° d ONLN dÑ ‡ú Îû ( Ëú.
° d ONLN dÜ Ù ä ˚ è ( ˙ än
° d ONLN dà Ú ñ ˝ ° ) Cr \ ° d ONLN dä Ú ° ˝ò ) 6eate a menu or menus if needed for your desk accessory –Ä ° d ONLN d¿ Úó ˝ú )ˆ. ¢‡ ° d ONLN d¬ Úú ˝¢ )Y c` ° d ONLN d√ Ú¢ ˝∏ )ou ar % ° d ONLN d» Úπ ˝ƒ )e r 3† ° d ONLN dÀ Úƒ ˝ ) esponsible for ° d ONLN d⁄ ˛ ñ 1 ( ñ adding your menu to the menu bar = ° d ONLN d˙ ˛1 ˙ )õ,. See the chapter “The Menu Manager” in the , ° d ONLN d& ˛˚ ) Inside ° d ONLN d-
ñ ˘ ( ñMacintosh: Macintosh T · ° d ONLN dC
¯ )boolbox ö ° d ONLN dI
Z ) volume for mor ç` ° d ONLN dX
ZÄ )H
e details. ° d ONLN dc ä' Ÿ ($ äIf your Open subr ∫Ä ° d ONLN dt Ÿ'í )O,outine is unable to complete its tasks (by r b† ° d ONLN d† ì'˜ )∫unning out of memory ™‡ ° d ONLN d¥ ˆ'
)c, for ° d ONLN d∫( ä3{ (0 ä3example), you should open only the minimum data str ¯‡ ° d ONLN dÌ({3í )Òuctur ~¿ ° d ONLN dÚ(ì3 ) es possible, modify the code ° d ONLN d4 ä? ≈ (< äso it doesn’t r ° d ONLN d 4 Δ?∑ )<8espond to events, and display an alert indicating failur M ° d ONLN dV4∑?æ )Òe. ° d ONLN dYF äQ (N ä#As for all drivers, your Close subr 1‡ ° d ONLN d|F Qˇ )ñ1outine should undo the actions taken by the Open ° d ONLN d≠R ä] ù (Z äsubr ¿ ° d ONLN d±R û] )Qoutine, disposing of the window and private storage, clearing the window pointer ° d ONLN d^ äi € (f äin the device contr Ä ° d ONLN d^ ‹i ˛ )Rol entry $¿ ° d ONLN d ^ ˝i )!, and r V‡ ° d ONLN d$^iv ) emoving the menu fr EÄ ° d ONLN d7^vi¡ )]om the menu bar ` ° d ONLN dF^¡i√ )K.
é Hî 4è Hî è äè
ˇ·ˇ‚7^
ˇˇ◊ ˇ◊ ° d ONLN dH~ äé! (ä äResponding to Events ˇˇˇˇˇˇ • (ä2
of your Contr ≠ ° d ONLN djπ Δƒ ‰ )<ol subr † ° d ONLN dqπ ƒ ) outine. ˇˇ@ . ° d ONLN dyÀ ä÷s (” ä3The Event Manager passes one of nine values in the ˇ˛Ä ° d ONLN d¨ t÷ò )ÍcsCode ˇˇ@ ° d ONLN d≤Àò÷° )$ fi @ ° d ONLN dµÀ°÷ ) eld to indicate the action . ° d ONLN d–◊ ä‚ ™ (fl äto take:
° d ONLN dŸ ä˙ « *
Constant name ¸î ° d ONLN dÁ «˙ Œ )=V ˆT ° d ONLN dË Õ˙ fi )alue ° d ONLN dÌ˙> )MMeaning ° d ONLN dıå˙é )r
. ° d ONLN d˘˝ ä ∫ ( äaccEvent . ° d ONLN d˛ Δ – )<64 ° d ONLN d˛D ¢ )~Handle a given event . ° d ONLN d ä Æ ( äaccRun . ° d ONLN d!
eld. ˜ ° d ONLN dÆÇç )Y ° d ONLN dØÇç: )ou can r fiÄ ° d ONLN d∑Ç9çÙ )"'espond to the event in whatever way is . ° d ONLN dfié äô û (ñ äappr I@ ° d ONLN d‚é üô )Topriate. For example, when your desk accessory becomes active you might install its ° d ONLN d 6ö ä• Î (¢ ämenu in the menu bar ¿@ ° d ONLN d Jö Ε )a. ˇ @ ˇ ˇˇˇˇ @
° d ONLN d h l sî * AIf your desk accessory’s window is a modeless dialog box and you ˇˇH . ° d ONLN d A t l v * ar R` ° d ONLN d C t v )
e calling the Dialog Manager r ç. ° d ONLN d a t )åoutine ,
Courier ˇ˛ê, ’D ° d ONLN d h s n )
IsDialogEvent ˇˇH ’D ° d ONLN d u tn )N in r 7– ° d ONLN d z tÄ § )esponse ° d ONLN d Ç Ä l ã ( à l!to the event, you should set the ° d ONLN d £ ã> )ñ
windowKind ° d ONLN d ≠ Ä> ãH )< fi ° d ONLN d ∞ ÄH 㧠)
eld of your window ˇˇÑÙ ° d ONLN d √ å l ó p ( î lr R` ° d ONLN d ƒ å p ó Ç )ecor $¿ ° d ONLN d » å Ç ó ¥ ) d to 2 befor Ö¸ ° d ONLN d ‘ å ¥ ó ı )2e you call the ˇˇ Ë ôà ° d ONLN d „ ã ı óC )A
IsDialogEvent ˇˇÑÙ ôà ° d ONLN d åC óI )N r Ò ° d ONLN d Ú åI ó£ )outine. Setting this . ° d ONLN d ò l £ r ( † lfi å¿ ° d ONLN d ò r £ )'eld to 2 allows the Dialog Manager to r kÄ ° d ONLN d0 ò £ã )¨ecognize and handle the ° d ONLN dH § l Ø ê ( ¨ levent pr ` ° d ONLN dP § ë Ø ≠ )%operly § ° d ONLN dV § ¨ Ø ± ). v` ° d ONLN dX § ± Ø ∑ )Y 6‡ ° d ONLN dY § ∑ Ø È ) ou should r † ° d ONLN dd § Í Ø ˇ )3estor ã ° d ONLN di § ˇ Ør ) e the original value of the . ° d ONLN dÖ Ø l ª ® ( ∏ l
windowKind ° d ONLN dè ∞ ® ª Ø )< f PÄ ° d ONLN dë ∞ Ø ª ‹ )
om your Contr ö ° d ONLN d∂ ∞W ªu )@ol subr l` ° d ONLN dΩ ∞u ªî ) outine. ˇˇ™™ ° d ONLN d≈ ¬ l Õ Ä ( lThe ˇˇUT *™ ° d ONLN d… ¡ Å Õ ∑ ) accCursor ˇˇ™™ *™ ° d ONLN d“ ¬ ∑ Õ¯ )6F message makes it possible to change the shape of the cursor when its . ° d ONLN d Œ l Ÿ ( ÷ lLinside your desk accessory window and your desk accessory window is active. <¿ ° d ONLN dd ŒÀ Ÿ— ( ÷ÀY ˝@ ° d ONLN de Œ– Ÿ· )our ° d ONLN di ⁄ l Â Ç ( ‚ lcontr >Ä ° d ONLN dn ⁄ É Â ë )ol r ·` ° d ONLN dr ⁄ ë ÂÒ )Poutine should check whether the mouse location is in your window; if it is, you ° d ONLN d¬ Ê l ÒZ ( Ó l6should set the cursor to the whatever cursor you desir €` ° d ONLN d¯ ÊZ Ò’ )Óe by calling the QuickDraw . ° d ONLN d Ú l ˝ p ( ˙ lr R` ° d ONLN d Ú p ˝ è )outine R` ° d ONLN d Ò è ˝ À )
InitCursor ï ° d ONLN d% Ú ˝ – );. ° d ONLN d( l} ( l;If your desk accessory window is a dialog box, you should r R` ° d ONLN dc}æ ( }espond to the R` ° d ONLN dqæÙ )A accCursor R` ° d ONLN dzÙ˜ )6 . ° d ONLN d{ lÍ ( lXmessage by generating a null event (storing the event code for a null event in an event ˇˇYJ . ° d ONLN d” l' p * r R` ° d ONLN d‘ p' Ç )ecor $¿ ° d ONLN dÿ Ç'> ))d) and passing it to the Dialog Manager r ¡p ° d ONLN d >'\ )ºoutine ˇ˛≤î ∫ ° d ONLN d]'• ) DialogSelect ˇˇYJ ∫ ° d ONLN d •'¯ )H. This enables the ° d ONLN d'( l3 (0 l Dialog Manager to blink the car R` ° d ONLN dF(3 )ñet in R` ° d ONLN dL'3J )editText R` ° d ONLN dT(J3l )0 items. ° d ONLN d]: lE (B l!When the Event Manager sends the ° d ONLN d~9E> )®accMenu ° d ONLN dÖ:>EÅ )* message, it pr R` ° d ONLN dî:ÅEfi )Covides the menu ID ° d ONLN dßF lQ- (N l(followed by the menu item number in the ° d ONLN dœE-QW )¡csParam ° d ONLN d÷FWQa )* fi ° d ONLN dŸFaQv )
eld. R` ° d ONLN dfiFvQ} )Y g` ° d ONLN dflF|Q÷ )ou should take the ˇ˛t9 ° d ONLN dÚR l] Ç (Z lappr R` ° d ONLN dˆR Ç]W )/opriate action and then call the Menu Manager r Δà ° d ONLN d%RW]t )’outine ˇ¸Ër :¡ ° d ONLN d,Qu]± )
HiliteMenu ˇ˛t9 :¡ ° d ONLN d6R±]¯ )< with a value of ° d ONLN dG^ li ó (f l
0 for the ° d ONLN dQ] ói ª )+menuID ° d ONLN dW^ ªi )$ parameter to r R` ° d ONLN df^i| )Femove the highlighting fr $¿ ° d ONLN d^|i» ){om the menu bar g` ° d ONLN dé^«i )K. ° d ONLN dêp l{ s (x lY ï ° d ONLN dëp r{ • ) ou should r g` ° d ONLN dúp •{ )3espond to the last fi g` ° d ONLN d±p{C )] ve messages— g` ° d ONLN dΩoC{m )AaccUndo g` ° d ONLN dƒpm{ )* thr 9¿ ° d ONLN d»p{ò )ough 9¿ ° d ONLN dÕoò{» )accClear 9¿ ° d ONLN d’p»{‡ )0—by . ° d ONLN dŸ| lá u (Ñ lpr G ° d ONLN d€| vá ¿ )
e the curr Ó† ° d ONLN d∏¶R±f ))ent r ° d ONLN dΩ¶g± )esour Y@ ° d ONLN d¬¶±ê )ce fi ‡ ° d ONLN d«¶ë±— )le and the curr K` ° d ONLN d÷¶—±· )@ent . ° d ONLN d⁄± lΩ ú (∫ lgrafPort ° d ONLN d‚≤ úΩ )0 if it changes either one.
√ *fi¯ 4√ *›¯
Ô *˜¯ 4Ô *ˆ¯ Ô *Ô˛
ˇ·ˇ‚7^
ˇˇ£‰ . ˇÆ ° d ONLN d˝€ *Ì y (È * Reference ˇˇˇˇˇˇ ⁄| (ÈÓ2
° d ONLN dˇ l
- ( l+This section describes the Device Manager r ˇ† ° d ONLN d2ˇ-
ì )¡outines, including the r üÄ ° d ONLN dJˇî
 )goutines that allow ° d ONLN d] l¶ ( lFyour application to communicate with existing device drivers and the r ņ ° d ONLN d£ ¶‹ (¶
outines that ° d ONLN d∞ l" u ( lpr G ° d ONLN d≤ v". )
(ovide support for your own device driver ≈Ä ° d ONLN d⁄-"Û )∑/. This sections ends with a description of the ° d ONLN d # l. | (+ l'DR rÄ ° d ONLN d # |. í )VR' r ±Ä ° d ONLN d# í. ™ )esour ˘¿ ° d ONLN d# ™. À )ce type. ˇÚ @ ˇ ˇˇˇˇ @
ˇˇ◊ ˇ◊ ° d ONLN d ] H m Ä ( i HData Str µ ° d ONLN d ] Ä m § )8uctur ôú ° d ONLN d
] • m ≤ )%es ˇˇˇˇˇˇ • ( i2
ó H õ 4 ò H ö " ò Ha
ˇ·ˇ‚7^
° d ONLN dˇˇ ( ï ä Listing 2-10 ° d ONLN d ç Œ ò. )DThe device control entry ,
Courier
. ° d ONLN d , § ä ∞ ( ≠ äTYPE DCtlEntry = ° d ONLN d > ≤ ä æ ñ * ° d ONLN d D ≤ ú æ ¿ )RECORD ° d ONLN d P ¿ Æ Ã + dCtlDriver: ° d ONLN d _ ¿ ˆ à )H Ptr; ° d ONLN d h ¿, ÃÏ )6 {pointer or handle to driver ° d ONLN d í ¿Ï ÃÚ )¿} ° d ONLN d ô Œ Æ ⁄ Í ( ◊ Æ
dCtlFlags: ° d ONLN d ß Œ ˆ ⁄2 )H
Integer; ° d ONLN d ¥ Œ2 ⁄h )< {flags ° d ONLN d ¿ Œh ⁄n )6} ° d ONLN d « ‹ Æ Ë ‰ ( Â Æ dCtlQHdr: ° d ONLN d ‘ ‹ ˆ Ë )H QHdr; ° d ONLN d fi ‹, ËÏ )6 {driver request queue header ° d ONLN d ‹Ï ËÚ )¿} ° d ONLN d Í Æ ˆ ¸ ( Û Æ
dCtlPosition: ° d ONLN d Í ¸ ˆ2 )N LongInt; ° d ONLN d, Í2 ˆû )6 {byte position} ° d ONLN dD ¯ Æ ˆ ( Æ dCtlStorage: ° d ONLN dT ¯ ˆ, )H Handle; ° d ONLN d` ¯,‘ )6 {handle private storage} ° d ONLN dÇ Æ ( Æ dCtlRefNum: ° d ONLN dë ˆ2 )H
Integer; ° d ONLN dû2‘ )< {driver reference number ° d ONLN dæ‘⁄ )¢} ° d ONLN d≈ Æ ¸ ( Æ
dCtlCurTicks: ° d ONLN d÷ ¸ 2 )N LongInt; ° d ONLN d‚2 § )6 {used internally ° d ONLN d˚§ ™ )r} ° d ONLN d" Æ. (+ Æ dCtlWindow: ° d ONLN d" ˆ.> )H WindowPtr; ° d ONLN d ">.
)H" {pointer to desk accessory window ° d ONLN dO"
. )Ã} ° d ONLN dV0 Æ< Í (9 Æ
dCtlDelay: ° d ONLN dd0 ˆ<2 )H
Integer; ° d ONLN dq02<˛ )<" {ticks between periodic actions ° d ONLN d†0˛< )Ã} ° d ONLN dß> ÆJ Í (G Æ
dCtlEMask: ° d ONLN dµ> ˆJ2 )H
Integer; ° d ONLN d¬>2J )<# {event mask for desk accessories ° d ONLN dÚ>J
)“} ° d ONLN d˘L ÆX ‰ (U Æ dCtlMenu: ° d ONLN dL ˆX2 )H
Integer; ° d ONLN dL2XÚ )< {menu ID for desk accessories ° d ONLN d@LÚX¯ )¿} ° d ONLN dBZ äf ê (c ä ° d ONLN dCZ êf ñ ) ° d ONLN dDZ ñf ú ) ° d ONLN dIZ úf ¥ )END;
v HÖ 4v HÖ
. ° d ONLN dˇˇ (} äField descriptions
ˇ·ˇ‚7^
. ° d ONLN dNÉ äè Δ *
dCtlDriver . ° d ONLN dYÑ Êè• )\,Contains a pointer or a handle to the driver P¿ ° d ONLN dÖÑ•è )ø, as determined by bit Æ ° d ONLN dúÑè )b6 . ° d ONLN dûê Êõ (ò Êof the ° d ONLN d•èõ; ) dCtlFlags ° d ONLN dÆê;õE )6 fi ° d ONLN d±êEõW )
eld. ° d ONLN d∂û ä™ ¿ (ß ä dCtlFlags . ° d ONLN d¿ü Ê™ )\
Contains fl £¿ ° d ONLN dÀü™Ÿ )0/ags about the abilities and state of the driver ¡ ° d ONLN d˙üŸ™ )√
. The low- ° d ONLN d´ Ê∂ Ô (≥ Êor ∫Ä ° d ONLN d´ Ô∂\ ) der byte contains these fl ñ@ ° d ONLN d ´]∂p )nags:
° d ONLN d'ª Ê≈ Ò (¬ ÊBit r! ° d ONLN d,ª Ú≈ ) Meaning
° d ONLN d5Δ Ê— Î (Œ Ê5 ° d ONLN d7Δ Î—C )Set if driver is open. ° d ONLN dO“ Ê› Î (⁄ Ê6 ° d ONLN dQ“ Λç )(Set if driver is RAM-based, that is, if . ° d ONLN d}fi ÊÈ ˘ (Ê Êthe ° d ONLN dÅ› ˘È5 )
dCtlDriver ° d ONLN dãfi5È? )< fi ° d ONLN défi?ȶ )
eld contains a handle. . ° d ONLN d¶Í Êı Î (Ú Ê7 ° d ONLN d®Í Îı= )Set if driver is curr µ† ° d ONLN dΩÍ=ıÉ )Rently executing. . ° d ONLN dœ˘ Ê ( Ê The high-or R` ° d ONLN d⁄˘ v )8der byte contains fl R` ° d ONLN dÓ˘vÖ )Xags R` ° d ONLN dÚ˘Ö± )
copied fr $¿ ° d ONLN d¸˘±‘ ),om the $¿ ° d ONLN d¯‘
)# drvrFlags $¿ ° d ONLN d ˘
)6 . ° d ONLN d
Ê ˜ (
Êwor Ä ° d ONLN d ¯> )d of the driver r Ú@ ° d ONLN d!=U )Eesour :Ä ° d ONLN d&Vu )ce. See «` ° d ONLN d.uÖ ) “Cr £` ° d ONLN d1ÖË )eating a Driver Resour i@ ° d ONLN dGÈ )dce” on ° d ONLN dN Ê ( Êpage 2- Æ¿ ° d ONLN dU ) 5 Æ¿ ° d ONLN dV . ) for mor y@ ° d ONLN d^/ m )$e information. . ° d ONLN dm ä+ ∫ (( ädCtlQHdr . ° d ONLN dv Ê+~ )\#Contains the header of the driver r ,` ° d ONLN dô +Ì )ôequest queue, which is a ° d ONLN d≤, Ê7 (4 Êstandar ±Ä ° d ONLN dπ,7¸ )!5d Operating System queue. See the chapter “Operating ° d ONLN dÓ8 ÊCN (@ ÊSystem Utilities” in the ˜ ° d ONLN d8NC‚ )h"Inside Macintosh: Operating System s† ° d ONLN d)8„C )ï volume . ° d ONLN d1D ÊO (L Êfor mor R` ° d ONLN d8DOw )!e information about the R` ° d ONLN dPCwOè )pQHdr R` ° d ONLN dTDèO√ ) data type. ° d ONLN d`R ä^ à ([ ä dCtlPostion . ° d ONLN dlS Ê^3 )\Indicates the curr y† ° d ONLN d~S3^W )Ment sour U† ° d ONLN dÜSW^‹ )$ ce or destination position for r ó` ° d ONLN d¶S‹^ )Ö
eading or ° d ONLN d∞_ Êj' (g Êwriting. This fi ·Ä ° d ONLN d¿_'j˝ )A2eld is only used by drivers of block devices. The ° d ONLN dÚk Êv$ (s Êvalue in this fi _ ° d ONLN dk%vı )?/eld is the number of bytes beyond the physical ° d ONLN d1w ÊÇÏ ( Ê9beginning of the medium used by the device. For example, ° d ONLN djÉ ÊéÅ * #immediately after the Disk Driver r C ° d ONLN dçÉÇéØ )ú
eads the fi OÄ ° d ONLN dòÉØéˇ )-rst block of data fr Ê¿ ° d ONLN d¨Éˇé )Pom ° d ONLN dØè ÊöC (ó Êa 3.5-inch disk, this fi Â` ° d ONLN d«èCö¥ )]eld contains the value 512 ‡ ° d ONLN d·èµö∑ )r. ˇ @ ˇ ˇˇˇˇ @
. ° d ONLN d \ l h Æ ( e l dCtlStorage . ° d ONLN d ] » hH )\ Contains a handle to a driver ÷ ° d ONLN d ) ]I hô )Å’s private storage. KÄ ° d ONLN d = ]ö h° )QA Ü ° d ONLN d > ]° h◊ ) driver may ° d ONLN d J i » t ˜ ( q » allocate a r Ä ° d ONLN d V i ¯ tÊ )06elocatable block of memory and keep a handle to it in ° d ONLN d å u » Ä ‡ ( } »this fi E‡ ° d ONLN d ì u · Ä Ò )eld. . ° d ONLN d ò É l è ® ( å l
dCtlRefNum . ° d ONLN d £ Ñ » è$ )\Contains the driver r í† ° d ONLN d ∏ Ñ$ è4 )\efer >¿ ° d ONLN d º Ñ5 èn ) ence number Δ† ° d ONLN d « Ñm èo )8. . ° d ONLN d … í l û ¥ ( õ l dCtlCurTicks . ° d ONLN d ÷ ì » û )\Used internally ∑Ä ° d ONLN d  ì û
)C. . ° d ONLN d Á ° l ≠ ® ( ™ l
dCtlWindow . ° d ONLN d Ú ¢ » ≠† )\/Contains a pointer to the desk accessory window 7 ° d ONLN d! ¢† ≠¢ )ÿ. ∑ ° d ONLN d" ¢¢ ≠µ ) See ä ° d ONLN d' ¢∂ ≠“ )“Refer ‰@ ° d ONLN d- ¢“ ≠Ì ) ence” ° d ONLN d3 Æ » π ı ( ∂ »
on page 2- u† ° d ONLN d= Æ ˆ π ).34 u† ° d ONLN d? Æ π# )
for mor @ ° d ONLN dG Æ$ π` )$
e information E ° d ONLN dT Æ` πb )<. . ° d ONLN dV º l » ¢ ( ≈ l dCtlDelay . ° d ONLN d` Ω » »Ÿ )\>Indicates the number of ticks to wait between periodic actions #‡ ° d ONLN dû Ω⁄ »‹ ( ≈⁄. . ° d ONLN d† À l ◊ ¢ ( ‘ l dCtlEMask . ° d ONLN d™ à » ◊è )\,Contains the desk accessory event mask. See ņ ° d ONLN d÷ Ãè ◊´ )«“Refer €¿ ° d ONLN d‹ ô ◊Î ) ence” on page ° d ONLN dÍ ÿ » „ – ( ‡ »2- ”‡ ° d ONLN dÏ ÿ – „ ⁄ )34 ”‡ ° d ONLN dÓ ÿ ⁄ „ ˝ )
for mor û` ° d ONLN dˆ ÿ ˛ „: )$
e information £` ° d ONLN d ÿ: „< )<. . ° d ONLN d Ê l Ú ú ( Ô ldCtlMenu . ° d ONLN d Á » Ú¡ )\7Contains the menu ID of a desk accessory’s menu, if any ó‡ ° d ONLN dE Á¿ Ú¬ )¯. ‡ ° d ONLN dF Á√ Ú÷ ) See ° d ONLN dK Û » ˛ ‰ ( ˚ »“Refer ⁄ ° d ONLN dQ Û ‰ ˛- ) ence” on page 2- $† ° d ONLN da Û. ˛8 )J34 $† ° d ONLN dc Û8 ˛[ )
for mor Ô ° d ONLN dk Û[ ˛ó )#
e information Ù ° d ONLN dx Ûó ˛ô )<.
*#¯ 4 *#¯ l ¯
ˇ·ˇ‚7^
° d ONLN dz l ˛ ( lThe Extended Device Contr ˝Ä ° d ONLN dì ˛ ( )íol Entry ˇˇˇˇˇˇ )Ù2
data type in µ ° d ONLN dßN £Y )7“The extended device contr . ° d ONLN d¡N Yt )zol entry” on page 2- ‡† ° d ONLN d’NtY~ )W35 ‡† ° d ONLN d◊N~Y‡ )
, contains additional fi WÄ ° d ONLN dÔN·Yı )celds ° d ONLN dÙZ le à (b lto stor q¿ ° d ONLN d˚Z àe « ) e these values.
á *㯠4à *ä¯ "à *a
ˇ·ˇ‚7^
° d ONLN dˇˇ (Ö l Listing 2-11 ° d ONLN d } ∞à7 )D!The extended device control entry
. ° d ONLN d-î l† ∫ (ù l
TYPE AuxDCE= ° d ONLN d;¢ lÆ x * ° d ONLN d=¢ xÆ ~ ) ° d ONLN d>¢ ~Æ ¢ )RECORD ° d ONLN dJ∞ êº “ + dCtlDriver: ° d ONLN dY∞ ÿº ¸ )H Ptr; ° d ONLN db∞ºŒ )6 {pointer or handle to driver ° d ONLN då∞Œº‘ )¿} ° d ONLN dìæ ê à (« ê
dCtlFlags: ° d ONLN d°æ ÿ )H
Integer; ° d ONLN dÆæ J )< {flags ° d ONLN d∫æJ P )6} ° d ONLN d¡Ã êÿ Δ (’ ê dCtlQHdr: ° d ONLN dŒÃ ÿÿ )H QHdr; ° d ONLN dÿÃÿŒ )6 {driver request queue header ° d ONLN dÃŒÿ‘ )¿} ° d ONLN d ⁄ êÊ fi („ ê
dCtlPosition: ° d ONLN d⁄ fiÊ )N LongInt; ° d ONLN d&⁄ÊÄ )6 {byte position} ° d ONLN d>Ë êÙ ÿ (Ò ê dCtlStorage: ° d ONLN dNË ÿÙ )H Handle; ° d ONLN dZËÙ∂ )6 {handle private storage} ° d ONLN d|ˆ ê “ (ˇ ê dCtlRefNum: ° d ONLN d㈠ÿ )H
Integer; ° d ONLN dòˆ∂ )< {driver reference number ° d ONLN d∏ˆ∂º )¢} ° d ONLN dø ê fi (
ê
dCtlCurTicks: ° d ONLN d– fi )N LongInt; ° d ONLN d‹Ü )6 {used internally ° d ONLN dıÜå )r} ° d ONLN d¸ ê “ ( ê dCtlWindow: ° d ONLN d ÿ )H WindowPtr; ° d ONLN d Ï )H" {pointer to desk accessory window ° d ONLN dIÏ Ú )Ã} ° d ONLN dP ê, Ã () ê
dCtlDelay: ° d ONLN d^ ÿ, )H
Integer; ° d ONLN dk ,‡ )<" {ticks between periodic actions ° d ONLN dö ‡,Ê )Ã} ° d ONLN d°. ê: Ã (7 ê
dCtlEMask: ° d ONLN dØ. ÿ: )H
Integer; ° d ONLN dº.:Ê )<# {event mask for desk accessories ° d ONLN dÏ.Ê:Ï )“} ° d ONLN dÛ< êH Δ (E ê dCtlMenu: ° d ONLN d < ÿH )H
Integer; ° d ONLN d
<H‘ )< {menu ID for desk accessories ° d ONLN d:<‘H⁄ )¿} ° d ONLN dAJ êV Δ (S ê dCtlSlot: ° d ONLN dNJ ÿV )H
Integer; ° d ONLN d\J VD )H {slot ° d ONLN ddJDVJ )$} ° d ONLN dkX êd à (a ê
dCtlSlotId ° d ONLN dyX ÿd )H
Integer; ° d ONLN dáX dV )H {slot ID ° d ONLN dìXVd\ )6} ° d ONLN döf êr fi (o ê
dCtlDevVBase: ° d ONLN d´f fir )N Integer; ° d ONLN d∏f rÊ )B! {base address of card for driver ° d ONLN dÊfÊrÏ )Δ} ° d ONLN dÌt êÄ Δ (} ê reserved: ° d ONLN d˙t ÿÄ )H
Integer; ° d ONLN dt Ä™ )H {reserved; should be 0 ° d ONLN d&t™Ä∞ )ä} ° d ONLN d-Ç êé “ (ã ê dCtlExtDev: ° d ONLN d<Ç ÿé )H
Integer; ° d ONLN dJÇ éò )H {external device ID ° d ONLN ddÇòéû )x} ° d ONLN dkê êú Δ (ô ê fillByte: ° d ONLN dxê ÿú )H
Integer; ° d ONLN dÜê ú\ )H
{reserved ° d ONLN dìê\úb )<} ° d ONLN dïû l™ r (ß l ° d ONLN dñû r™ x ) ° d ONLN dóû x™ ñ ) END; ˇ‰ @ ˇ ˇˇˇˇ @
° d ONLN d ] ä h £ ( e äThe fi »Ä ° d ONLN d ] £ h ÷ ) rst eleven fi ° d ONLN d ] ◊ hh )4!elds of the extended device contr r¿ ° d ONLN d 4 ]h hï )ë ol entry ar Ù¿ ° d ONLN d ? ]ï hÊ )-e identical to the fi LJ ° d ONLN d T ]Á h )Relds of ° d ONLN d \ i ä t – ( q äthe device contr …¿ ° d ONLN d l i – t Ú )Fol entry Î ° d ONLN d t i Ò tH )!, described in the pr £‡ ° d ONLN d â iI tâ )Xevious section.
dCtlExtDev . ° d ONLN d0 º Ê «s )\ Contains the external device ID. ° d ONLN dQ Œ ä Ÿ ( ÷ äVThe chapter “The Slot Manager” in this book contains detailed information about these ° d ONLN dß ⁄ ä  ´ * values.
H 4 H H
ˇ·ˇ‚7^
ˇˇ◊ ˇ◊ ° d ONLN d∞ H Ö ( HRoutines ˇˇˇˇˇˇ • (2
° d ONLN dπ ä* Ú (' äThe Device Manager pr d@ ° d ONLN dŒ Ú*M )hovides a number of r Ä ° d ONLN d‚ N*é )\outines that pr ¶ ° d ONLN dÒ é* )@ ovide low-level support for ° d ONLN d
+ ä6 È (3 äyour own driver subr Ü@ ° d ONLN d!+ È6 )_outines. ˇˇ: . ° d ONLN d*= äH û (E äThe ˇ˛t6 ∫ ° d ONLN d.< ûH Ê ) GetDCtlEntry ˇˇ: ∫ ° d ONLN d:= ÊH
)HC function allows your driver to obtain a handle to its device contr Eø ° d ONLN d}= H (E ol . ° d ONLN dÄI äT ° (Q äentry √` ° d ONLN dÖI †T • ). ˇˇéú . ° d ONLN dà[ äf û (c äThe ˇˇ 8 ú ° d ONLN dåZ üf √ )IODone ˇˇéú ú ° d ONLN dí[ √f … )$ r oò ° d ONLN dî[ …fÌ )?outine allows your driver to notify the Device Manager that a r b¨ ° d ONLN d”[Ìf (cÌ
É ° d ONLN d n Å z … ) GetDCtlEntry ˇˇÜÉ É ° d ONLN d o … z ˆ )H function r ÂÈ ° d ONLN d ' o ı zì ),#eturns a handle to the device contr fl[ ° d ONLN d J oì z˜ )ûol entry of the device . ° d ONLN d a { l Ü ◊ ( É ldriver indicated by the r Ë@ ° d ONLN d z { ◊ Ü& )kefNum parameter É` ° d ONLN d â {& Ü( )O.
. ° d ONLN d Ï l Å +BThe ° d ONLN d Å ü )Fetch ° d ONLN d ı ü ¶ ) r R` ° d ONLN d ˜ ¶ : )!outine gets the next character fr $¿ ° d ONLN d: Ñ )îom the data buf ˜ ° d ONLN d'É Ê )Ifer pointed to by the ° d ONLN d= l ú ( lioBuffer ° d ONLN dE
ú £ )0 f PÄ ° d ONLN dG
£p ),ield of the parameter block of the pending r "‡ ° d ONLN ds
pÆ )Õequest. It incr ı@ ° d ONLN dÇ
≠‚ )= ements the ˇˇ«$ ° d ONLN dç l$ ® (! l
ioActCount ˇˇ„í ° d ONLN dó ®$ Æ )< f 4 ° d ONLN dô Ø$ ˚ )ield by 1. If the ˇˇ«$ •Ï ° d ONLN d´ ˚$7 )L
ioActCount ˇˇ„í •Ï ° d ONLN dµ7$= )< f Y˛ ° d ONLN d∑>$Ü )ield equals the ˇˇ«$ ¥ ° d ONLN d«á$√ )I
ioReqCount ˇˇ„í ¥ ° d ONLN d—√$… )< f ∏Δ ° d ONLN d”…$˜ ) ield, this . ° d ONLN dfi% l0 – (- lfunction sets bit 15 of r ’ ° d ONLN d˜% –0 )d egister D0. 0† ° d ONLN d%0 )2After r è` ° d ONLN d
% 0Ç ) eceiving the last byte r ó@ ° d ONLN d"%Ç0Ú )cequest, the driver should ° d ONLN d<1 l< ∑ (9 lcall the IODone r ÎÄ ° d ONLN dM1 ∑< ’ )Koutine.
° d ONLN dU@ lK ∫ (H lRegisters on entry
° d ONLN dhO lZ x *A1 ° d ONLN dkO ®Z )<pointer to the device contr ±† ° d ONLN dÜO Z> )tol entry
° d ONLN dè^ li ¥ (f lRegisters on exit
° d ONLN d°m lx x *D0 ° d ONLN d§m ®x≥ )<Ccharacter fetched; bit 15 = 1 if it’s the last character in the buf @ ° d ONLN dÁm¥x¿ (u¥fer
° d ONLN dÎ| lá ° (Ñ l Jump vector
° d ONLN d¯ã lñ á *JFetch
÷ *fi¯ 4◊ *fi¯ ◊ *◊˛
ˇ·ˇ‚7^
° d ONLN d… *÷ G (” *Stash ˇˇˇˇˇˇ (”Ú2
. ° d ONLN d È lÙ s (Ò lY ï ° d ONLN d
È rÙ µ )ou can use the ï ° d ONLN dË µÙ ” )CStash ï ° d ONLN d È ”Ù ⁄ ) r g` ° d ONLN d È ⁄Ù )outine to stor 9¿ ° d ONLN d.ÈÙ~ )<e the next character fr ° d ONLN dEÈ~Ù» )hom the data buf fiÄ ° d ONLN dTÈ«Ù‘ )Ifer ! ° d ONLN dWÈ‘Ù◊ )
+eld of the parameter block of the pending r n˙ ° d ONLN d¯-Ä8√ )«equest and incr ‡¨ ° d ONLN d-√8˜ )C ements the ˇˇ«$ ° d ONLN d8 lD ® (A l
ioActCount ˇˇ„í ° d ONLN d 9 ®D Æ )< f 4 ° d ONLN d 9 ØD ˚ )ield by 1. If the ˇˇ«$ •Ï ° d ONLN d08 ˚D7 )L
ioActCount ˇˇ„í •Ï ° d ONLN d:97D= )< f Y˛ ° d ONLN d<9>DÜ )ield equals the ˇˇ«$ ¥ ° d ONLN dL8áD√ )I
ioReqCount ˇˇ„í ¥ ° d ONLN dV9√D… )< f ∏Δ ° d ONLN dX9…D˜ ) ield, this . ° d ONLN dcE lP – (M lfunction sets bit 15 of r ’ ° d ONLN d|E –P )d egister D0. 0† ° d ONLN dàEP~ )2 After stashing the last byte r Õ‡ ° d ONLN d¶E~Pÿ )|equested, the driver . ° d ONLN dªQ l\ ∂ (Y lshould call the ° d ONLN dÀP ∂\ ⁄ )JIODone ° d ONLN d—Q ⁄\ · )$ r R` ° d ONLN d”Q ·\ )outine.
. ° d ONLN d€w * P (} *ASSEMBL ‹è ° d ONLN d‚w P T )&Y ö∫ ° d ONLN d„w U ≤ )-LANGUAGE INFORMA —U ° d ONLN dÙw ≤ « )]TION
° d ONLN d˘â lî ∫ (ë lRegisters on entry
° d ONLN d ò l£ x *A1 ° d ONLN dò ®£ Í )<pointer to DCE ° d ONLN d ® l≥ x (∞ lD0 ° d ONLN d!® ®≥ Ù )<character to stash ˇ∞ @ ˇ ˇˇˇˇ @
. ° d ONLN d ⁄* ä5 ü +BThe ° d ONLN d fi) ü5 √ )IODone ° d ONLN d ‰* √5 )$ r R` ° d ONLN d Ê* 5 Ì )outine r $¿ ° d ONLN d Ó* Ì55 )#emoves the curr ˜ ° d ONLN d ˝*45I )Gent r …Ä ° d ONLN d*I5p ) equest fr õ‡ ° d ONLN d *p5∑ )'om the driver r n@ ° d ONLN d*∑5 )Gequest queue, marks . ° d ONLN d.6 äAâ (> ä<the driver inactive, unlocks the driver and its device contr ‡ ° d ONLN dj6âA˝ )ˇ ol entry (if allowed by the ° d ONLN dÜB äM( (J ä"dNeedLock bit of the dCtlFlags wor 6 ° d ONLN d®B)Mª )ü!d), and executes the completion r ê‡ ° d ONLN d…BªMÚ )í
outine if any T@ ° d ONLN d÷BÚM )7. Then ° d ONLN d›N äY. (V ä$the Device Manager begins the next r æ@ ° d ONLN dN.Yä )§equest in the driver r &Ä ° d ONLN dNãY« )]
equest queue. ° d ONLN d%] äh æ (e ä The section , Times $@ ° d ONLN d1\ øhÇ )5-“Responding to the Device Manager” on page 2- V‡ ° d ONLN d^\Çhá )√9 V‡ ° d ONLN d_]áh ) explains in detail when to use ° d ONLN di ät † (q äthis r ˛ ° d ONLN dÖi †t æ )outine.
° d ONLN dçè Hó n (ï HASSEMBL ‹è ° d ONLN dîè nó r )&Y ö∫ ° d ONLN dïè só – )-LANGUAGE INFORMA —U ° d ONLN d¶è –ó  )]TION
° d ONLN dæ∞ äª ñ *A1 ° d ONLN d¡∞ Δª )< pointer to DCE ° d ONLN d—¿ äÀ ñ (» äD0 ° d ONLN d‘¿ ΔÀ à )< r ≈ ° d ONLN d÷¿ ÃÀ ¯ )
esult code
° d ONLN d·œ ä⁄ ø (◊ ä Jump vector
. ° d ONLN dÓ› äÈ ¥ *JIODone
. ° d ONLN d˜ H o (
HSEE ALSO
° d ONLN d ä +B For an example of the IODone r 6‡ ° d ONLN d G )å outine, see …Ä ° d ONLN d*G )1+“Responding to the Device Manager” on page ° d ONLN dU ä) í (& ä2- ”‡ ° d ONLN dW í) ó )9 ”‡ ° d ONLN dX ó) ô ).
U H] 4V H] V HV
ˇ·ˇ‚7^
ˇˇ◊ ˇ◊ ° d ONLN dZE HU x (Q HResour ' ° d ONLN d`E yU ç )1ces ˇˇˇˇˇˇ • (Q2
° d ONLN ddb äm (j ä#This section describes the driver r ˜Ä ° d ONLN dáb m6 )îesour ?¿ ° d ONLN dåb7m≈ ) ce, which you should use to stor f` ° d ONLN d¨b≈m )ée your device ° d ONLN d∫n äy (v ä drivers and desk accessories. ∞ ° d ONLN dÿn y? )Ç Listing 2-12 P` ° d ONLN d‰n@y– )4 shows the Rez format of the 'DR ®‡ ° d ONLN dn–yÊ )êVR' r Á‡ ° d ONLN d nÊy˛ )esour 0 ° d ONLN dnˇy
)ce . ° d ONLN dz äÖ fi (Ç ätype. The driver r R` ° d ONLN d#z fiÖ ı )Tesour $¿ ° d ONLN d(z ıÖ- ) ce has type $¿ ° d ONLN d4y-ÖQ )8'DRVR' $¿ ° d ONLN d:zQÖT )$. ˇÏ @ ˇ ˇˇˇˇ @
í )Í/* DA event mask */ ° d ONLN dö 6' f ($ 6integer; ° d ONLN dØ 'n )Í
/* DA menu */ ° d ONLN dæ) 65 ¥ (2 6unsigned hex integer; ° d ONLN d‡) 5ò )Í/* offset to Open */ ° d ONLN dˆ7 6C ¥ (@ 6unsigned hex integer; ° d ONLN d7 Cû )Í/* offset to Prime */ ° d ONLN d/E 6Q ¥ (N 6unsigned hex integer; ° d ONLN dQE Q§ )Í/* offset to Control*/ ° d ONLN diS 6_ ¥ (\ 6unsigned hex integer; ° d ONLN dãS _§ )Í/* offset to Status */ ° d ONLN d£a 6m ¥ (j 6unsigned hex integer; ° d ONLN d≈a mû )Í/* offset to Close */ ° d ONLN d‹o 6{ l (x 6 pstring; ° d ONLN dÚo {Ü )Í/* driver name */ ° d ONLN d} 6â x (Ü 6 hex string; ° d ONLN d } âÜ )Í/* driver code */ ° d ONLN d/ã *ó 6 (î *}; . ° d ONLN d2§ lØ ° +B The driver r Z ° d ONLN d>§ °Ø π )5esour ¢@ ° d ONLN dC§ πØ )ce begins with seven fl [ ° d ONLN dZ§ Ø· )d0ags that specify certain characteristics of the ° d ONLN dä∞ lª á (∏ ldriver ‡ ° d ONLN dê∞ ᪠å ). ˇˇ‰î . ° d ONLN dì¬ lÕ s ( lY ï ° d ONLN dî¬ rÕ ≈ )ou need to set the ˇˇ…( ‰ ° d ONLN dß¡ ΔÕ ¸ )T dNeedLock ˇˇ‰î ‰ ° d ONLN d∞¬ ¸Õ )6 fl x ° d ONLN d≥¬ÕQ ) ag if your driver [î ° d ONLN dƒ¬SÕÛ )N"’s code should be locked in memory õL ° d ONLN dʬÚÕ˜ )ü. ° d ONLN dÈ‘ lfl s (‹ lY ï ° d ONLN dÍ‘ rfl ¢ ) ou set the ï ° d ONLN dı” ¢fl ÿ )0 dNeedTime ï ° d ONLN d˛‘ ÿfl ‚ )6 fl ï ° d ONLN d‘ ‚fl )
ag of the ï ° d ONLN d ”flE )- drvrFlags ï ° d ONLN d‘EflY )6 wor g` ° d ONLN d‘YflÌ )!d if your device driver needs to . ° d ONLN d9‡ lÎ ˛ (Ë l perform some action periodically U ° d ONLN dY‡ ˛Î )í. . ° d ONLN d\Ú l˝ s (˙ lY ï ° d ONLN d]Ú r˝ Δ )ou need to set the ï ° d ONLN dpÒ Δ˝ )T dNeedGoodbye ï ° d ONLN d|Ú˝ )H fl ï ° d ONLN dÚ˝æ )
$ag if you want your application to r g` ° d ONLN d£Úæ˝Á )¶ eceive a . ° d ONLN d¨˛ l Ø ( l
goodBye Contr o† ° d ONLN dπ˛ Ø Ω )Col r Ä ° d ONLN dΩ˛ æ Ù ) equest befor % ° d ONLN d…˛ Ù 1 )6e the heap is r SÄ ° d ONLN dÿ˛1 d )=
einitialized. ° d ONLN dÊ l ¨ ( lThe last four fl Û` ° d ONLN dˆ ¨O )@#ags indicate which Device Manager r r` ° d ONLN dPü )§equests the driver V@ ° d ONLN d+†≠ )P’s r üÄ ° d ONLN d/≠· )
outines can ° d ONLN d; l' o ($ lr E ° d ONLN d< p' û )
espond to. ° d ONLN dG. l9 ⁄ (6 lThe next element of the r ZÄ ° d ONLN d`. ⁄9 Ú )nesour ¢¿ ° d ONLN de. Ú9 ) ce specifi ¿ ° d ONLN do.9≥ )(#es the time between periodic tasks. ° d ONLN dì@ lK ‹ (H lThe next two elements pr Å¿ ° d ONLN d´@ ‹K )p:ovide an event mask and menu ID for desk accessories. The ° d ONLN dÂL lW ç (T lsection ËÄ ° d ONLN dÌL çW ú )!“W + ° d ONLN dÔL úW ◊ )riting a Desk ° d ONLN d˝L ◊W9 );Accessory” on page 2- ^@ ° d ONLN dL9WC )b31 ^@ ° d ONLN dLCWê )
describes these fi ‡ ° d ONLN d'LêW§ )Melds. ° d ONLN d-^ li w (f lOf Ç ° d ONLN d/^ wi ) fsets to the driver r Ä ° d ONLN dD^ Àig )T#outines follow the desk accessory fi ,Ä ° d ONLN dh^gi¡ )úelds. See the section P ° d ONLN d~^¡iÓ )Z
“Entering ° d ONLN dàj lu ´ (r land Exiting Fr y@ ° d ONLN dñj ´u )?om Driver Subr Q ° d ONLN d§j uE )Eoutines” on page 2- F ° d ONLN d∑jFuK )V9 F ° d ONLN d∏jKun ) for mor Ä ° d ONLN d¿jouŸ )$e information about the ° d ONLN dÿv lÅ (~ lsubr ¿ ° d ONLN d‹v ÄÅ ß ) outine of n‡ ° d ONLN dÂv ßÅ Ω )'fsets. ° d ONLN dÏà lì ˜ (ê l The next element of the driver r 3¿ ° d ONLN d à ¯ì )åesour | ° d ONLN dàìq )ce is the driver name. S@ ° d ONLN d(àqìw )aY ¿ ° d ONLN d)àwì√ )ou can use upper ˘¿ ° d ONLN d9à¬ìÍ )K case and ° d ONLN dBî lü Ö (ú llower √Ä ° d ONLN dGî Öü* )$case letters when naming your driver 6@ ° d ONLN dkî*üV )• , but the fi ÒÄ ° d ONLN dwîVüÎ ),!rst character should be a period— . ° d ONLN dòü l´ Æ (® l .YourDriver ¬† ° d ONLN d£† ≠´ Ì )A, for example. ˇ Ë @ ˇ ˇˇˇˇ @
° d ONLN d ] ä h ê ( e äY @Ä ° d ONLN d ] ê h √ ) our driver r Œ ° d ONLN d
] √ h· )3?outines, which follow the driver name, must be aligned on a wor Δ¿ ° d ONLN d L ]· hÈ ( e·d ° d ONLN d N i ä t µ ( q äboundary ◊` ° d ONLN d V i ¥ t ∂ )*. ° d ONLN d X { ä Ü æ ( É ä The section $@ ° d ONLN d d { ø Ü œ )5“Cr @ ° d ONLN d g { œ Ü2 )eating a Driver Resour Δ ° d ONLN d } {2 Üp )cce” on page 2- u† ° d ONLN d ã {q Üv )?5 u† ° d ONLN d å {v ܬ ) discusses this str ≈‡ ° d ONLN d ü {¬ ÜŸ )Luctur K¿ ° d ONLN d § {⁄ Ü ) e in detail.
ã H ¶ 4 å H ¶
∑ H ø 4 ∏ H ø ∏ H ∏
ˇ·ˇ‚7^
ˇˇ£‰ ˇÆ ° d ONLN d ± § H ∂ í ( ≤ HSummary ˇˇˇˇˇˇ ⁄| ( ≤ 2
nitions fr ™@ ° d ONLN d Ô »j ”Æ )(om this chapter ±‡ ° d ONLN d ˛ »Æ ”≥ )D. Ñ@ ° d ONLN d »≥ ”π )Y D¿ ° d ONLN d »π ” )ou might want to ° d ONLN d ‘ ä fl ( ‹ äWsupplement this information with the information in the summary section of the chapter ° d ONLN di ‡ ä Î Í * “The Device Manager _¿ ° d ONLN d| ‡ Í Î* )`,” in this book.
H 4 H H
ˇ·ˇ‚7^
° d ONLN dç
H } ( H Constants ,
Courier
. ° d ONLN dó& H2 ¥ *{Chooser messages} ° d ONLN d™> HJ ñ *
CONST initMsg ° d ONLN dΩ> ÆJ ¥ )f= ° d ONLN dø> ¿J “ )11; ° d ONLN dƒ> ‰JŒ )$'{the user selected this device package} ° d ONLN dÌL TX ê (U T
newSelMsg ° d ONLN d¸L ÆX ¥ )Z= ° d ONLN d˛L ¿X “ )12; ° d ONLN dL ‰X¬ )$%{the user made new device selections} ° d ONLN d*Z Tf ú (c T fillListMsg ° d ONLN d;Z Æf ¥ )Z= ° d ONLN d=Z ¿f “ )13; ° d ONLN dBZ ‰f∂ )$#{fill the device list with choices} ° d ONLN dgh Tt ê (q T
getSelMsg ° d ONLN duh út ¢ )H ° d ONLN dwh Æt ¥ )= ° d ONLN dyh ¿t “ )14; ° d ONLN d~h ‰t» )$&{mark one or more choices as selected} ° d ONLN d¶v TÇ ê ( T
selectMsg ° d ONLN d¥v úÇ ¢ )H ° d ONLN d∂v ÆÇ ¥ )= ° d ONLN d∏v ¿Ç “ )15; ° d ONLN dΩv ‰ÇÜ )${the user made a selection} ° d ONLN d⁄Ñ Tê ú (ç T deselectMsg ° d ONLN dÍÑ úê ¢ )H ° d ONLN dÏÑ Æê ¥ )= ° d ONLN dÓÑ ¿ê “ )16; ° d ONLN dÛÑ ‰ê§ )$ {the user cancelled a selection} ° d ONLN dí Tû ¢ (õ T
° d ONLN d \ * i M ( f *Data T ˘@ ° d ONLN d \ L i d )"ypes ,
Courier
. ° d ONLN d u * Å ê ( ~ *TYPE DCtlEntry = ° d ONLN d É * è 6 * ° d ONLN d É 6 è < ) ° d ONLN d ! É < è ` )RECORD ° d ONLN d * ë H ù ä + dCtlDriver: ° d ONLN d : ë ¢ ù ∫ )ZPtr; ° d ONLN d B ë Í ùò )H { pointer or handle to driver ° d ONLN d l ë‘ ù⁄ )Í} ° d ONLN d p ü H ´ Ñ ( ® H
dCtlFlags: ° d ONLN d ü ¢ ´ “ )ZInteger; ° d ONLN d ã ü Í ´ )H{ flags ° d ONLN d ü ü‘ ´⁄ )Í} ° d ONLN d £ ≠ H π ~ ( ∂ H dCtlQHdr: ° d ONLN d ± ≠ ¢ π ¿ )ZQHdr; ° d ONLN d ∫ ≠ Í πò )H { driver request queue header ° d ONLN d ‰ ≠‘ π⁄ )Í} ° d ONLN d Ë ª H « ñ ( ƒ H
dCtlPosition: ° d ONLN d ˙ ª ¢ « “ )ZLongInt; ° d ONLN d ª Í «Œ )H&{ byte position used by I/O operations ° d ONLN d9 ª‘ «⁄ )Í} ° d ONLN d= … H ’ ê ( “ H dCtlStorage: ° d ONLN dN … ¢ ’ à )ZHandle; ° d ONLN dY … Í ’¬ )H${ handle to driver’s private storage ° d ONLN dä …‘ ’⁄ )Í} ° d ONLN dé ◊ H „ ä ( ‡ H dCtlRefNum: ° d ONLN dû ◊ ¢ „ “ )ZInteger; ° d ONLN d™ ◊ Í „Ä )H{ driver reference number ° d ONLN d– ◊‘ „⁄ )Í} ° d ONLN d‘  H Ò ñ ( Ó H
dCtlCurTicks: ° d ONLN dÊ Â ¢ Ò “ )ZLongInt; ° d ONLN dÚ Â Í ÒP )H{ used internally ° d ONLN d ‘ Ò⁄ )Í} ° d ONLN d Û H ˇ ä ( ¸ H dCtlWindow: ° d ONLN d$ Û ¢ ˇ fi )Z
WindowPtr; ° d ONLN d2 Û Í ˇò )H { pointer top driver’s window ° d ONLN d\ Û‘ ˇ⁄ )Í} ° d ONLN d` H
Ñ (
H
dCtlDelay: ° d ONLN do ¢
“ )ZInteger; ° d ONLN d{ Í
™ )H { ticks between periodic actions ° d ONLN d®‘
⁄ )Í} ° d ONLN d¨ H Ñ ( H
dCtlEMask: ° d ONLN dª ¢ “ )ZInteger; ° d ONLN d« ͺ )H#{ event mask (for desk accessories) ° d ONLN d˜‘⁄ )Í} ° d ONLN d˚ H) ~ (& H dCtlMenu: ° d ONLN d ¢) “ )ZInteger; ° d ONLN d Í)™ )H { menu ID (for desk accessories) ° d ONLN dB ‘)⁄ )Í} ° d ONLN dD+ *7 0 (4 * ° d ONLN dE+ 07 6 ) ° d ONLN dF+ 67 < ) ° d ONLN dH+ <7 T )END; ° d ONLN dM9 *E 0 (B * ° d ONLN dN9 0E 6 ) ° d ONLN dP9 6E f )DCTlPtr ° d ONLN d^9 ¢E ® )l= ° d ONLN d`9 ¥E ˆ ) ^DCtlEntry; ° d ONLN dlG *S 0 (P * ° d ONLN dmG 0S 6 ) ° d ONLN doG 6S r )
DCtlHandle ° d ONLN dG ¢S ® )l= ° d ONLN dÅG ¥S Í ) ^DCtlPtr; ° d ONLN dçm 6y f (v 6AuxDCE= ° d ONLN dñ{ *á 6 (Ñ * ° d ONLN dô{ 6á Z ) RECORD ° d ONLN d¢â Hï ä + dCtlDriver: ° d ONLN d≤â ¢ï ∫ )ZPtr; ° d ONLN d∫â Íïí )H {pointer or handle to driver ° d ONLN d◊âíïò )®} ° d ONLN d€ó H£ Ñ († H
dCtlFlags: ° d ONLN dÍó ¢£ “ )ZInteger; ° d ONLN dˆó Í£ )H{flags ° d ONLN d˛ó£ )$} ° d ONLN d• H± ~ (Æ H dCtlQHdr: ° d ONLN d• ¢± ¿ )ZQHdr; ° d ONLN d• ͱò )H {driver request queue header} ° d ONLN d9≥ Hø ñ (º H
. ° d ONLN d ! † H ¨ “ *FUNCTION GetDCtrlEntry ° d ONLN d B † Ú ¨¨ )™ (refNum: Integer) : DCtlHandle;
› H „ 4 fi H „ fl H fl
ˇ·ˇ‚7^
. ° d ONLN d b – H › ¯ ( ⁄ H Assembly-Language Information
° d ONLN d Ä Û H ˇ ‘ *"Routines Requiring Jump V J» ° d ONLN d ô Û ‘ ˇ )åectors
° d ONLN d †
H i ( HRoutine ° d ONLN d ®
¬ ‚ )zJump V Å ° d ONLN d Æ
‚ ˜ ) ector
° d ONLN d ¥ H$ _ (! HFetch ° d ONLN d ∫ ¬$ › )zJFetch ° d ONLN d ¡) H4 _ (1 HStash ° d ONLN d «) ¬4 ‹ )zJStash ° d ONLN d Œ9 HD k (A HIODone ° d ONLN d ’9 ¬D Ë )zJIODone ˇ¯ @ ˇ ˇˇˇˇ @
° d ONLN d = ∫H *—Intr ∑@ ° d ONLN d = H: )oduction to Slots and Car œÄ ° d ONLN d .=:HD )pds (@ ° d ONLN d 2=YHf ) 3-3 ° d ONLN d 6J ƒU € (R ƒAddr C¿ ° d ONLN d :J ‹U )ess allocations lÄ ° d ONLN d KJ/U< )S3-5 ° d ONLN d OW ƒb Í (_ ƒFirmwar ⁄ ° d ONLN d VW Íb Ó )&e £¿ ° d ONLN d YWb )3-7 ° d ONLN d ]d Œo (l ŒThe format block Û ° d ONLN d od-o: )_3-7 ° d ONLN d sq Œ| (y Œ The sResour Ô ° d ONLN d ~q| )6ce dir r ° d ONLN d Ñq |8 )ectory ÂÄ ° d ONLN d åqL|Y )/3-8 ° d ONLN d ê~ Œâ Ò (Ü ŒsResour ≥@ ° d ONLN d ó~ Òâ )# ce Data Str MÄ ° d ONLN d ¢~!â8 )0uctur ”` ° d ONLN d ß~8âA )es ⁄ ° d ONLN d ´~Uâb ) 3-8 ° d ONLN d Øã Œñ Ò (ì ŒsResour ≥@ ° d ONLN d ∂ã Òñ )#ce T ߇ ° d ONLN d ∫ãñO )ypes and sResour ` ° d ONLN d ãPñz )Nce Names CÄ ° d ONLN d ‘ãèñ° )?3-10 ° d ONLN d Ÿò Œ£ ı († ŒThe Boar ° d ONLN d ·ò ˆ£! )( d sResour · ° d ONLN d Íò!£* )+ce ‡ ° d ONLN d Óò?£L ) 3-1 ‚ ° d ONLN d ÒòK£P ) 1 ° d ONLN d Û• ∫∞# (≠ ∫About the Slot Manager ]@ ° d ONLN d •8∞J )~3-12 ° d ONLN d≤ ∫Ω" (∫ ∫Using the Slot Manager úÄ ° d ONLN d(≤6ΩH )|3-14 ° d ONLN d-ø ƒ _ (« ƒ Enabling and Disabling NuBus Car @Ä ° d ONLN dMø` j )úds ô@ ° d ONLN dQø~ ê ) 3-14 ° d ONLN dVà ƒ◊P (‘ ƒ Deleting and Restoring sResour åÄ ° d ONLN dtÃP◊ )å ce Data Str &¿ ° d ONLN dÃÄ◊ó )0uctur ¨† ° d ONLN dÑÃó◊† )es ≥@ ° d ONLN dàÃ¥◊Δ ) 3-15 ° d ONLN dçŸ ƒ‰R (· ƒ Enabling and Disabling sResour a‡ ° d ONLN d´ŸR‰Å )é ce Data Str ¸ ° d ONLN d∂ŸÅ‰ò )/uctur Ç ° d ONLN dªŸô‰¢ )es à† ° d ONLN døŸ∂‰» ) 3-15 ° d ONLN dƒÊ ƒÒ ÷ (Ó ƒSear N` ° d ONLN d»Ê ◊Ò$ )ching for sResour » ° d ONLN dŸÊ$ÒS )M ce Data Str b` ° d ONLN d‰ÊTÒk )0uctur Ë@ ° d ONLN dÈÊkÒt )es Ó‡ ° d ONLN dÌÊàÒö ) 3-16 ° d ONLN dÚÛ ƒ˛& (˚ ƒGetting Information fr ¿ ° d ONLN dÛ'˛[ )c
om sResour ˇÄ ° d ONLN dÛZ˛â )3 ce Data Str ô¿ ° d ONLN d Û䲰 )0uctur † ° d ONLN d"Û¢˛´ )es &@ ° d ONLN d&Ûø˛— ) 3-18 ° d ONLN d+ ∫ — ( ∫Refer ⁄ ° d ONLN d0 — = )ence to the Slot Manager ∂@ ° d ONLN dJ R d )Å3-20 ° d ONLN dO
ƒ Á ( ƒData Str `` ° d ONLN dW
Ë ˇ )$uctur Ê@ ° d ONLN d\
ˇ )es χ ° d ONLN d`
. ) 3-20 ° d ONLN de ƒ% (" ƒDetermining the V ’‡ ° d ONLN dv%â )Qersion of the Slot Manager ° d ONLN díû%∞ )â3-22 ° d ONLN dó' ƒ2 (/ ƒFinding sResour ‡¿ ° d ONLN d¶' 2; )H ce Data Str { ° d ONLN d±'<2S )0uctur ‡ ° d ONLN d∂'T2] )es Ä ° d ONLN d∫'q2É ) 3-24 ° d ONLN dø4 ƒ?Æ (< ƒ4Enabling, Disabling, Deleting, and Restoring sResour N ° d ONLN dÛ4Ø?∏ )Îce ° d ONLN dˆ? ƒJ Á (G ƒData Str `` ° d ONLN d˛? ËJ ˇ )$uctur Ê@ ° d ONLN d? ˇJ )es χ ° d ONLN d? J. ) 3-35 ° d ONLN d L ƒW& (T ƒGetting Information fr ¿ ° d ONLN d"L'W[ )c
om sResour ˇÄ ° d ONLN d,LZWâ )3 ce Data Str ô¿ ° d ONLN d7LäW° )0uctur † ° d ONLN d<L¢W´ )es &@ ° d ONLN d@LøW— ) 3-40 ° d ONLN dEY ƒdr (a ƒ%Loading Drivers and Executing Code fr ∂ ° d ONLN djYrd¶ )Æ
om sResour ≤‡ ° d ONLN dtY¶d± )4ce ° d ONLN dxd ƒo Á (l ƒData Str `` ° d ONLN dÄd Ëo ˇ )$uctur Ê@ ° d ONLN dÖd ˇo )es χ ° d ONLN dâd o. ) 3-53 ° d ONLN déq ƒ| (y ƒT ∫¿ ° d ONLN dèq …| )raversing Firmwar o‡ ° d ONLN d†q |o )Se of Expansion Car „ ° d ONLN d≤qo|y )Sds ;¿ ° d ONLN d∂qé|† ) 3-57 ° d ONLN dª~ ƒâ| (Ü ƒ'Getting Information about Expansion Car ê† ° d ONLN d‚~|âú )∏ds and ° d ONLN dÍâ ƒî (ë ƒDeclaration ROMs ‡ ° d ONLN d¸â*î< )f3-58 ° d ONLN dñ ƒ° Á (û ƒGetting ⁄ ° d ONLN d ñ Á°S )#Access to Expansion Car ]` ° d ONLN d ñT°´ )mds’ Parameter RAM ` ° d ONLN d3ñ¿°“ )l3-65 ° d ONLN d8£ ∫Æ> (´ ∫Summary of the Slot Manager ` ° d ONLN dU£SÆe )ô3-69 ˇå @ ˇ ˇˇˇˇ @
ˇˇ—Ú ˇÆ ° d ONLN d 8 ä C Œ ( @ äThe Slot Manager ˇˇˇˇˇˇ ≠> ( @3
° d ONLN d \ ä h ( e äYThis chapter describes how your application or device driver can use the Slot Manager to ° d ONLN d j h ä t Ï * identify expansion car î ° d ONLN d Ä h Ï tw )b ds and communicate with the fi b ° d ONLN d û hx tñ )årmwar D¿ ° d ONLN d £ hñ tŒ )
e on each car ¿ ° d ONLN d ∞ hœ t◊ )9d. ° d ONLN d ≥ z ä Ü ê ( É äY @Ä ° d ONLN d ¥ z ê Ü\ ).ou need to use the Slot Manager only if you ar ‡ ° d ONLN d ‚ z\ Ü˙ )Ã%e writing an application or a device ° d ONLN d Ü ä í È ( è ädriver that must addr ` ° d ONLN d Ü Í íD )`ess an expansion car † ° d ONLN d0 ÜD íY )Zd dir gÄ ° d ONLN d5 ÜY ím )ectly ?Ä ° d ONLN d: Üm í )#. For example, you need to use the ° d ONLN d] í ä û Ï ( õ äSlot Manager if you ar ˇ ° d ONLN ds í Ï û{ )b"e writing a driver for a video car 9‡ ° d ONLN dï í| û )ê d, but not if you only want to ° d ONLN d¥ û ä ™ù ( ß ä>display information on a monitor for which a device driver alr ≠† ° d ONLN dÚ ûù ™– ( ßù eady exists. ° d ONLN dˇ ∞ ä º ‰ ( π äThe Slot Manager pr Ù‡ ° d ONLN d ∞ ‰ º )Zovides r `` ° d ONLN d ∞ ºq )$outines to help you sear ÙÄ ° d ONLN d2 ∞q ºä )ich thr é‡ ° d ONLN d8 ∞ã º÷ )ough the data str ÖÄ ° d ONLN dI ∞÷ ºÌ )Kuctur ` ° d ONLN dN ∞Ó º
)es that ° d ONLN dV º ä » « ( ≈ ä
expansion car g@ ° d ONLN dc º « » ˙ )= ds use to or @ ° d ONLN do º ˙ »â )3!ganize the information in their fi Í@ ° d ONLN dë ºâ »ß )èrmwar Ç ° d ONLN dñ ºß » ) e. The meaning of the ° d ONLN d¨ » ä ‘ ˛ ( — äinformation in the data str é† ° d ONLN d« » ˛ ‘ )tuctur Ä ° d ONLN dà » ‘E ) es varies fr ª‡ ° d ONLN dÿ »E ‘c )/om car ∫† ° d ONLN dfi »c ‘Ñ ) d to car √Ä ° d ONLN dÊ »Ñ ‘Ò )!d; you need to know the ° d ONLN d˛ ‘ ä ‡ ¶ ( › äspecifi Ó ° d ONLN d ‘ ¶ ‡ — ) cs of a car ° d ONLN d ‘ “ ‡ Ô ),d in or * ° d ONLN d ‘ Ô ‡* ) der to interpr 9` ° d ONLN d% ‘* ‡b );et its data str È@ ° d ONLN d4 ‘b ‡y )8uctur o ° d ONLN d9 ‘z ‡à )es. ° d ONLN d> Ê ä Ú Õ ( Ô äThis chapter pr ° ° d ONLN dM Ê Õ Ú )Covides a brief intr à¿ ° d ONLN d` Ê ÚP )N oduction to \Ä ° d ONLN dl ÊP Ú˛ )5$Apple’s implementation of NuBus and ° d ONLN dê Ú ä ˛ « ( ˚ ä
° d ONLN dWp ñ|ó ) ;determine the version of the Slot Manager that is available
° d ONLN dìÖ äå è (ã än
° d ONLN dïÇ ñé ú ) fi å¿ ° d ONLN dóÇ úé )nd information in the fi Ÿ ° d ONLN dØÇé! )grmwar ª¿ ° d ONLN d¥Ç!é} ) e of an expansion car á` ° d ONLN d…Ç~éÑ )]d
° d ONLN dÀó äû è (ù än
° d ONLN dÕî ñ† ) enable and disable data str x† ° d ONLN dËî †# )vuctur ˛Ä ° d ONLN dÌî#†v )es in expansion car ¶ ° d ONLN d îw†Ö )Td fi N† ° d ONLN dî܆§ )rmwar 1@ ° d ONLN d ® ) e
¶ ñ≤# ) load drivers and execute code fr @ ° d ONLN d-¶$≤q )éom expansion car — ° d ONLN d=¶q≤ )Md fi yÄ ° d ONLN dA¶Ä≤û )rmwar \ ° d ONLN dF¶û≤¢ ) e
° d ONLN dHª ä¬ è (¡ än
° d ONLN dJ∏ ñƒ& ) !check the status of expansion car Ä ° d ONLN dk∏'ƒ1 )ëds
° d ONLN dnÕ ä‘ è (” än
° d ONLN dp ñ÷ ô ) r E ° d ONLN dq ö÷L )%ead and change the slot parameter RAM
€ Hˆ 4‹ Hˆ
H 4 H H
ˇ·ˇ‚7^
ˇˇ£‰ ˇÆ ° d ONLN dóÙ H3 ( H Introduction to Slots and Cards ˇˇˇˇˇˇ ⁄| ( 3
° d ONLN d∑ ä#e ( ä/The Macintosh family of computers supports a pr h ° d ONLN dÊe#Ö )€ocessor À‡ ° d ONLN dÌÖ#ï ) -dir ˇ ° d ONLN dÒï# )ect slot (PDS) expansion ° d ONLN d
# ä/I (, ä+interface and a NuBus expansion interface. ° d ONLN d65 äA ù *The ª¿ ° d ONLN d:5 ùA » ) processor ‡ ° d ONLN dC5 »A ˚ )+
-direct slot, ÚÄ ° d ONLN dP5 ˚A )3 or Z† ° d ONLN dT5
A! )PDS, f ° d ONLN dX5!AÇ ) is connected to the pr Q‡ ° d ONLN do5ÇA )a ocessor bus, which gives it dir ¿ ° d ONLN dé5A )Öect ° d ONLN díA äM ◊ (J äaccess to the micr ´ ° d ONLN d§A ◊M Ê )Mopr Á† ° d ONLN dßA ÊM. )ocessor and ther † ° d ONLN d∑A/M@ )Iefor `† ° d ONLN dªA@M )+e a speed advantage over the NuBus. However >¿ ° d ONLN dÊAM )œ, ° d ONLN dËM äYî (V ä=since the PDS expansion interface is an extension of the micr ◊¿ ° d ONLN d %MîY£ (Vîopr ` ° d ONLN d (M§Yƒ )ocessor ËÄ ° d ONLN d /M√Yÿ ) , the ° d ONLN d 5Y äe ü (b äconfi C‡ ° d ONLN d :Y †eÇ )2guration of the slot connector depends on which pr j‡ ° d ONLN d lYÇe )‚ ocessor is used by the computer √† ° d ONLN d ãYe )å. ° d ONLN d çe äq Ô (n äFor information specifi †¿ ° d ONLN d §e ÔqS )ec to PDS expansion car 6¿ ° d ONLN d ∫eTqs )eds, see fl¿ ° d ONLN d ¬esq ) $Designing Cards and Drivers for the ° d ONLN d Êq ä} ” (z äMacintosh Family Á@ ° d ONLN d ˆq ”} ’ )I. ° d ONLN d ¯ï ä°\ (û ä.The Macintosh II-family computers include the ¿ ° d ONLN d
&ï]°| )”NuBus ª‡ ° d ONLN d
+ï|°Ì ) expansion interface with ° d ONLN d
E° ä≠ ü (™ äconfi C‡ ° d ONLN d
J° †≠ ˘ )gurations ranging fr 0@ ° d ONLN d
^° ˘≠ )Y>om one to six identical slot connectors. The Macintosh system ° d ONLN d
ú≠ äπ ß (∂ äuses a ¿ ° d ONLN d
£≠ ßπ Δ ) slot ID )` ° d ONLN d
™≠ «πò ) 1 in the range $09 to $0E to identify NuBus slots. ˇ ƒ @ ˇ ˇˇˇˇ @
° d ONLN d g l s Ò * For convenience, this section r ìÄ ° d ONLN d g Ò sR )Öefers to a NuBus confi €‡ ° d ONLN d 5 gR s† )aguration with six ° d ONLN d G s l Ü ( | lslots r fl@ ° d ONLN d N s Ü î )epr p ° d ONLN d Q s ï )esented by slot IDs $09 thr fi‡ ° d ONLN d l s ä )t ough $0E. Keep in mind that ° d ONLN d à l ãî ( à lAsome Macintosh family computers use only some of these slot IDs. ° d ONLN d … ã l ój * :For example, the Macintosh IIcx uses only slot IDs $09 thr "@ ° d ONLN d ãk óô )ˇ
ough $0B. ° d ONLN d
ó l £ } ( † lSee ” ° d ONLN d ó } £! )%Guide to the Macintosh Family Hardwar ‡ ° d ONLN d6 ó" £% )•e cÄ ° d ONLN d7 ó& £I ) for mor . ° d ONLN d? óJ £ã )$e information. ,
byte lane ° d ONLN dù¡ lÕ ò ( lswapping z` ° d ONLN d•¡ ôÕ )- between the two buses. ° d ONLN dæ” lfl( (‹ l)The bus interface also performs some addr ¿Ä ° d ONLN dÁ”(fl˜ )º/ess translation between the two buses. It maps ° d ONLN dfl lÎ ° (Ë l certain addr % ° d ONLN d"fl ¢Î )6ess ranges on each bus ar %` ° d ONLN d;flÎ/ )oe to dif —@ ° d ONLN dCfl/Î; ) fer ≥¿ ° d ONLN dFfl;Î` ) ent addr
† ° d ONLN dNflaÎ⁄ )& ess ranges on the other bus. ° d ONLN dkÒ l˝L (˙ l4Designing Cards and Drivers for the Macintosh Family “‡ ° d ONLN düÒL˝— )‡ discusses byte lanes and addr X¿ ° d ONLN dΩÒ“˝· )Üess ° d ONLN d¡˝ l ª ( ltranslation in mor † ° d ONLN d”˝ ª › )O e detail. ° d ONLN d› l ∏ ( lThe next section, *@ ° d ONLN dÔ π ’ )M“Addr Ó ° d ONLN dÙ ’ ) ess allocations,” ñ¿ ° d ONLN d o )G discusses the addr )¿ ° d ONLN dpÊ )Tess ranges assigned by the ° d ONLN d3 l' • ($ l Macintosh ar *Ä ° d ONLN d? ¶' à ): chitectur fl@ ° d ONLN dH Ã'+ )&e to each NuBus slot. ° d ONLN d_- l9 † (6 l The section $@ ° d ONLN dk- °9 à )5“Firmwar ~` ° d ONLN ds- Ã9 ÿ )+e,” » ° d ONLN dv- ÿ9 Ë ) on ‡ ° d ONLN dz- È9 )page 3- =† ° d ONLN dÅ- 9 ) 7 =† ° d ONLN dÇ-9 ) intr ~¿ ° d ONLN dá- 9s )oduces the data str ßÄ ° d ONLN dö-s9ä )Suctur -` ° d ONLN dü-ã9£ )es car È@ ° d ONLN d•-£9œ ) d’s use to ° d ONLN d∞9 lE u (B lor ∫Ä ° d ONLN d≤9 uE Ù ) ganize information in their fi @ ° d ONLN d–9 ıE )Ärmwar ȇ ° d ONLN d’9E ) e.
k *q¯ 4k *p¯ k lk¯
ˇ·ˇ‚7^
ˇˇ◊ ˇ◊ ° d ONLN dÿY lj ë (f lAddr „@ ° d ONLN d‹Y ëj Û )%ess allocations ˇˇˇˇˇˇ ® (f3
° d ONLN dÏp l| π (y lThe Macintosh ar f@ ° d ONLN d¸p π| fl )M chitectur ° d ONLN dp ‡|? )'e assigns certain addr ↠° d ONLN dp?|Ÿ )_#ess ranges to each NuBus slot. The ° d ONLN d>| là u (Ö lpr G ° d ONLN d@| và< )
slot: a 256-m ° d ONLN d í ¬ ûß )82egabyte super slot space and a 16-megabyte standar ` ° d ONLN dM íß û‹ )Â
d slot space. ° d ONLN d[ § ä ∞+ ( ≠ ä%The four gigabytes of the 32-bit addr ¿ ° d ONLN dÄ §, ∞ä )¢ess space contain 16 r C† ° d ONLN dñ §ä ∞¯ )^egions of 256 megabytes ° d ONLN dÆ ∞ ä º- ( π ä&apiece, each of which constitutes the £¿ ° d ONLN d‘ ∞- ºu )£super slot space “Ä ° d ONLN d‰ ∞u º˙ )H for one possible slot ID. Each ° d ONLN d º ä » ( ≈ ä super slot space spans an addr t ° d ONLN d" º »z )áess range $s000 0000 thr Í@ ° d ONLN d: ºz »Ø )i ough $sFFF ±¿ ° d ONLN dE º∞ »Δ )6FFFF @ ° d ONLN dI ºΔ »· ), wher ∫@ ° d ONLN dO º· » ) e s is a ° d ONLN dX » ä ‘ ı ( — ähexadecimal digit $0 thr T¿ ° d ONLN dp » ı ‘ )kough $F V ° d ONLN dw » ‘ )#. ° d ONLN dz ⁄ ä Ê Î ( „ äFor example, the addr ÀÄ ° d ONLN dè ⁄ Î Ê )aCess ranges $9000 0000 – $9FFF FFFF constitute the super slot space ° d ONLN d“ Ê ä Úø ( Ô äIfor slot ID $09. Since the Macintosh II family uses only slot IDs $09 thr ᇠ° d ONLN d Êø Ú ( Ôøough $0E, only six ° d ONLN d. Ú ä ˛ ( ˚ ä!super slot spaces, $9xxx xxxx thr
‡ ° d ONLN dO Ú ˛s )êough $Exxx xxxx, ar  ° d ONLN db Úr ˛∂ )Xe actually used. ° d ONLN ds ä ù (
äThe ª¿ ° d ONLN dw ù ¯ )standard slot spaces ` ° d ONLN dã ¯ )[ ar ` ° d ONLN dé® ) #e 16 megabytes apiece and have addr ~` ° d ONLN d±® )§esses of the form $Fsxx ° d ONLN d… ä fl ( äxxxx (that is, $Fs00 > ° d ONLN dfi ‡ M )V0000 – $FsFF FFFF) wher o¿ ° d ONLN dıM ó )me s is the slot ID. ì¿ ° d ONLN d ó )JAs with super slot spaces, ° d ONLN d$ ä( (% ä the Macintosh uses only standar ˝Ä ° d ONLN dC (c )éd slot spaces corr …‡ ° d ONLN dU d(fi )L esponding to slot IDs $9 thr ƒ¿ ° d ONLN dq fi( )zough $E ° d ONLN dy( ä4 Î (1 ä(that is $F9xx xxxx thr ´ ° d ONLN dê( Î4< )aough $FExx xxxx). ° d ONLN d¢: äF ¢ (C äFigur R¿ ° d ONLN dß: ¢F ∂ )e 3-2 @ ° d ONLN d¨: ∂FJ )! shows the super slot and standar „‡ ° d ONLN dÕ:JFÎ )î&d slot subdivisions of the 32-bit addr é ° d ONLN dÛ:ÏF
° d ONLN d~ ää ï (á äIn /‡ ° d ONLN d~ ñä Æ ) Figur † ° d ONLN d ~ Æä ¬ )e 3-2 † ° d ONLN d#~ ¬äe )&, the super slot space and the standar “@ ° d ONLN dI~eä‰ )£ d slot space for slot ID $09 ar >@ ° d ONLN dh~Âä )Ä e shaded. ° d ONLN drê äúo (ô ä2In 24-bit mode, the Macintosh system can only addr çÄ ° d ONLN d§êoú⁄ )Âess a fraction of each car É` ° d ONLN dæê⁄ú )kd’s allocated ° d ONLN dÃú ä® ü (• äaddr |Ä ° d ONLN d–ú ü®Œ )Eess range. In this mode, the system assigns each slot a one megabyte † ° d ONLN dúœ® (•œ minor slot ° d ONLN d ® ä¥ • (± äspace. ¸@ ° d ONLN d&® •¥S )) The bus interface translates 24-bit addr A` ° d ONLN dO®T¥ã )Ø
ess on the pr ` ° d ONLN d\®ã¥ )7 ocessor bus with the form $sx
\ ù hE )1(e s is a slot ID) into 32-bit NuBus addr –Ä ° d ONLN d 2 \E hÓ )®'esses of the form $Fs0x xxxx, which is ° d ONLN d Y h l t Ç ( q lthe fi Í ° d ONLN d _ h Ç t )"rst megabyte of the slot’s standar Â` ° d ONLN d Å h tI )í
d slot space. ° d ONLN d è z l Ü ÿ ( É lFor example, 24-bit addr Ù` ° d ONLN d ß z ÿ Ü9 )lesses in the range $90 rÄ ° d ONLN d æ z: Ü] )b0000 thr À@ ° d ONLN d Δ z] Üà )# ough $9F 7Ä ° d ONLN d œ zâ ܇ ),FFFF constitute the ° d ONLN d „ Ü l í » ( è lminor slot space corr ÈÄ ° d ONLN d ¯ Ü » íZ )\!esponding to slot ID $09. The har ¿ ° d ONLN d Ü[ ír )ìdwar XÄ ° d ONLN d Ür í‘ )e translates these addr ˜` ° d ONLN d4 Ü‘ íÏ )besses ° d ONLN d: í l û Δ ( õ linto the NuBus addr ` ° d ONLN dM í « û )[ess range $F900 p‡ ° d ONLN d] í û1 )G0000 thr …† ° d ONLN de í1 û} )#ough $F90F FFFF Ä ° d ONLN dt í} û )L. ° d ONLN dv § l ∞ r ( ≠ lT µ¿ ° d ONLN dw § q ∞ ì )able 3-1 √@ ° d ONLN d § ì ∞ Ÿ )" shows the addr 5 ° d ONLN dé § ⁄ ∞a )G!ess allocations for each slot ID.
” * €¯ 4 ‘ * €¯ ◊ l ◊¯
ˇ·ˇ‚7^
° d ONLN dˇˇ ( — l Table 3-1 ° d ONLN d∞ … ™ ‘ )>Slot allocations by slot ID ° d ONLN dÕ fi l È | ( Ê lSlot ° d ONLN d“ fi ê È ≈ )$
24-bit minor ° d ONLN d‡ fi ‰ È )T 32-bit minor ° d ONLN dÌ fiD Èj )`Standard ° d ONLN dˆ fi§ ÈΩ )`Super ° d ONLN d˝ È l Ù t ( Ò lID ° d ONLN d È ê Ù º )$
slot space ° d ONLN d È ‰ Ù )T
slot space ° d ONLN d ÈD Ùp )`
slot space ° d ONLN d! ȧ Ù– )`
slot space
° d ONLN d- ˙ l v ( l$9 ° d ONLN d0 ˙ ë ∑ )%$9x xxxx ° d ONLN d9 ˙ ‰ )S
$F90x xxxx ° d ONLN dD ˙Du )`
$F9xx xxxx ° d ONLN dO ˙§‘ )`
$9xxx xxxx ° d ONLN d[ l x ( l$A ° d ONLN d^ ë ∫ )%$Ax xxxx ° d ONLN dg ‰ Ó )S$F Q¿ ° d ONLN di Ó )
A0x xxxx ° d ONLN dr DN )V$F Q¿ ° d ONLN dt Nw )
Axx xxxx ° d ONLN d} §◊ )V
$Axxx xxxx ° d ONLN dâ l* w (' l$B ° d ONLN då ë* ∏ )%$Bx xxxx ° d ONLN dï ‰* )S
$FB0x xxxx ° d ONLN d† D*v )`
$FBxx xxxx ° d ONLN d´ §*’ )`
$Bxxx xxxx ° d ONLN d∑0 l< x (9 l$C ° d ONLN d∫0 ë< π )%$Cx xxxx ° d ONLN d√0 ‰< )S
$FC0x xxxx ° d ONLN dŒ0D<w )`
$FCxx xxxx ° d ONLN dŸ0§<÷ )`
$Cxxx xxxx ° d ONLN dÂB lN x (K l$D ° d ONLN dËB ëN ∫ )%$Dx xxxx ° d ONLN dÒB ‰N )S
$FD0x xxxx ° d ONLN d¸BDNw )`
$FDxx xxxx ° d ONLN dB§N◊ )`
$Dxxx xxxx ° d ONLN dT l` w (] l$E ° d ONLN dT ë` ∏ )%$Ex xxxx ° d ONLN d T ‰` )S
° d ONLN dIã ló Ö (î lThe fi »Ä ° d ONLN dOã Öó £ )rmwar ´ ° d ONLN dTã £ó ) e of a NuBus expansion car €@ ° d ONLN dnãóµ )x#d contains information that identifi œ` ° d ONLN díã∂ófl )õ
es the car ˆ ° d ONLN dúãflóÁ ))d ° d ONLN dûó l£ († l%and its functions, and allows the car z ° d ONLN d√ó £ø )ü&d to communicate with the Slot Manager ˝¿ ° d ONLN dÈó棈 )≥. It may also ° d ONLN d˜£ lØø (¨ lPinclude other information, such as initialization code or code for drivers that ° d ONLN dGØ lª * #communicate with devices on the car b` ° d ONLN djت— )§*d. The sole purpose of many Slot Manager r Õ` ° d ONLN dîØ—ªÛ )¡outines ° d ONLN dúª l« ä (ƒ lis to pr $` ° d ONLN d§ª ã« Ë ) ovide access to this fi /¿ ° d ONLN dªª Ë« )]rmwar ` ° d ONLN d¿ª«G ) e information. ° d ONLN d–Õ lŸ Í (÷ l This section discusses the str ÙÄ ° d ONLN dÓÕ ÍŸ )~uctur z` ° d ONLN dÛÕŸm )e of the information in fi φ ° d ONLN d
ÕmŸã )krmwar œ@ ° d ONLN dÕãŸî ) e. k@ ° d ONLN dÕïŸõ )
Y +¿ ° d ONLN dÕõŸ‘ )ou’ll need to ° d ONLN d$Ÿ lÂ Ω (‚ lunderstand the str ÿ` ° d ONLN d6Ÿ Ω ‘ )Quctur ^@ ° d ONLN d;Ÿ ’ÂF )e of this information in or Z ° d ONLN dVŸFÂ≈ )q der to use the Slot Manager r ° d ONLN dsŸΔÂÙ )Ä outines. If ° d ONLN d lÒ Δ (Ó lyou plan to design fi wÄ ° d ONLN dî «Ò  )[rmwar Z ° d ONLN dô ÂÒ÷ ) 7e, you will want to supplement the information in this ° d ONLN d–Ò l˝ ˜ (˙ l section with the information in é ° d ONLN dÒ ˜˝◊ )ã4Designing Cards and Drivers for the Macintosh Family ≈@ ° d ONLN d$Ò÷˝ÿ )fl. ° d ONLN d& l" ( l)The physical location of an expansion car ^ ° d ONLN dO"7 )∂d’s fi
‡ ° d ONLN dU8V )rmwar ÌÄ ° d ONLN dZUè ) e is called its j† ° d ONLN djê· );declaration ROM. ¿ ° d ONLN dz‚˜ )R The ° d ONLN d l r ( lfi å¿ ° d ONLN dÅ r ê )rmwar o` ° d ONLN dÜ ê ∑ )
e in a car ® ° d ONLN dê ∑Ä )',d’s declaration ROM includes these elements: ,
Zapf Dingbats
° d ONLN dΩ$ l+ q (* ln
° d ONLN dø! x- ã ) The ª¿ ° d ONLN d√! ã- » )
format block. ‘` ° d ONLN d–! »-ñ )=. The format block allows the Slot Manager to fi µ† ° d ONLN dˇ!ó-È )œnd the declaration ° d ONLN d- x9L (6 x0ROM and to validate it. It contains some identifi %Ä ° d ONLN dC-M9À )’ cation information and an of ° d ONLN d_-À9Ë )~fset to ° d ONLN dg9 xE ´ (B x the sResour † ° d ONLN dr9 ¨E ƒ )4ce dir ì† ° d ONLN dx9 ƒE fl )ectory Î` ° d ONLN d~9 fiE ‡ ).
° d ONLN dÄN lU q (T ln
° d ONLN dÇK xW ã ) The ª¿ ° d ONLN dÜK ãW ‰ )sResource directory Å` ° d ONLN dôK ‰W Ê )Y. ` ° d ONLN döK ÁW ) The sResour ` ° d ONLN d¶K W7 )8ce dir s` ° d ONLN d¨K8W∫ )!ectory is a list that contains of >Ä ° d ONLN dÕKªWı )Éfsets to all of ° d ONLN d›W xc ´ (` x the sResour † ° d ONLN dËW ¨c Ÿ )4 ce data str † ° d ONLN dÛW Ÿc )-uctur åÄ ° d ONLN d¯W c$ )
es in the car flÄ ° d ONLN dW$c9 )4d’s fi å@ ° d ONLN d W:cX )rmwar n‡ ° d ONLN dWXc_ ) e.
An sResour *¿ ° d ONLN d ∏´L∑y )4 ce data str ¿ ° d ONLN d √´y∑ê )-uctur ¶† ° d ONLN d »´ê∑õ )e r µ@ ° d ONLN d À´õ∑Í ) elating to a specifi òÄ ° d ONLN d fl´Î∑Ò )Pc ˇ,é @ ˇ ˇˇˇˇ @
ˇ·ˇ‚7^
4 H \ , Palatino
. +ä"CHAPTER €` )\3 , Helvetica
( @ äThe Slot Manager 4⁄ ä˙ (‡ ä Introduction to Slots and Cards
° d ONLN d \ ä h fl ( e äfunction is called a ⁄ ° d ONLN d \ fl hA )Ufunctional sResource, #@ ° d ONLN d * \B hl )c
and a car ≈† ° d ONLN d 4 \l h˘ )* d may have as many of them as ° d ONLN d R h ä t ¥ ( q ä necessary 4‡ ° d ONLN d [ h ¥ t π )*. ° d ONLN d ^ z ä ÜQ ( É ä.The next few sections discusses these data str 5 ° d ONLN d å zR Üi )»uctur ∫‡ ° d ONLN d ë zi Üë ) es in mor â¿ ° d ONLN d ö zí Ü¥ )) e detail.
§ H ´ 4 • H ´ ¶ ä ¶
ˇ·ˇ‚7^
° d ONLN d § ó ä • ‰ ( ° äThe format block ˇˇˇˇˇˇ ( °3
° d ONLN d µ ´ ä ∑ ˝ ( ¥ äThe format block always r √Ä ° d ONLN d Œ ´ ˝ ∑m )sesides at the highest addr T` ° d ONLN d Ë ´n ∑∫ )qess in the standar ‡† ° d ONLN d ˙ ´∫ ∑ )Ld slot space of a ° d ONLN d ∑ ä √Á ( ¿ äLdeclaration ROM. It contains information about the declaration ROM and an of çÄ ° d ONLN dX ∑Á √ ( ¿Á fset to the ° d ONLN dd √ ä œ ≠ ( à äsResour ≥@ ° d ONLN dk √ ≠ œ ≈ )#ce dir 6@ ° d ONLN dq √ Δ œ · )ectory é ° d ONLN dw √ ‡ œ )E. The Slot Manager uses the format block to validate the declaration ° d ONLN dº œ ä € ( ÿ äROM and locate the sResour W ° d ONLN d÷ œ €5 )~ ce data str M ° d ONLN d· œ5 €L )-uctur “‡ ° d ONLN dÊ œL €W )es. ° d ONLN dÍ · ä Ìf ( Í ä2The format block also contains a value that specifi °¿ ° d ONLN d ·f Ìˇ )‹$es which of the four byte lanes the ° d ONLN dA Ì ä ˘ ( ˆ ä!declaration ROM uses, called the o‡ ° d ONLN db Ì ˘f )îvalid byte lanes ° ° d ONLN dr Ìf ˘ )H#. Some declaration ROMs do not use ° d ONLN dï ˘ ä ( ä all four byte lanes and ther Ä ° d ONLN d± ˘ )wefor ^Ä ° d ONLN dµ ˘Ä )e the system cannot addr ∂ ° d ONLN dÕ ˘Ä )n ess every memory location in ° d ONLN dÍ ä ∂ ( ä
° d ONLN d∫L äZ À * The sResour “ ° d ONLN d≈L ÀZ Ë )Ace dir < ° d ONLN dÀL ÈZ ) ectory ˇˇˇˇˇˇ (V3
° d ONLN d“` äl ¿ (i ä The sResour Ô ° d ONLN d›` ¿l ÿ )6ce dir r ° d ONLN d„` ŸlL ) ectory lists all the sResour T ° d ONLN dˇ`Lly )s ce data str J ° d ONLN d
`ylê )-uctur œ‡ ° d ONLN d`êlƒ )
es in the car "‡ ° d ONLN d `≈l” )5d fi À` ° d ONLN d `”lÒ )rmwar Æ ° d ONLN d%`Òl ) e and ° d ONLN d+l äx ì (u äpr G ° d ONLN d-l îx … )
ovides an of ⁄¿ ° d ONLN d9l …x )5fset to each one. ° d ONLN dK~ ää ¢ (á äFigur R¿ ° d ONLN dP~ ¢ä ∂ )e 3-3 @ ° d ONLN dU~ ∂äF ) shows the format of the sResour ë‡ ° d ONLN du~Gä_ )ëce dir ‡ ° d ONLN d{~`ä{ )ectory l† ° d ONLN dÅ~zä| ).
≠ Hæ 4Æ Hæ "Æ H_
ˇ·ˇ‚7^
° d ONLN dˇˇ (´ ä
Figure 3-3 ° d ONLN dÉ£ ÃÆ fi )BThe Å ° d ONLN dᣠfiÆS ) sResource directory structure
° d ONLN d•Q ä] (Z äEach element of the sResour ‰` ° d ONLN d¿Q] )|ce dir g` ° d ONLN dΔQ ]´ ) ectory contains an 8-bit sResour ÷ ° d ONLN dÊQ´] )åce ID followed by a 24- ° d ONLN d˝] äi † (f äbit of N ° d ONLN d] °i » )
fset. The &¿ ° d ONLN d
] …i )(
sResource ID u† ° d ONLN d]i' )?identifi L@ ° d ONLN d"](ig ) es the sResour cÄ ° d ONLN d0]giî )? ce data str YÄ ° d ONLN d;]îi´ )-uctur fl` ° d ONLN d@]´i )e. Each sResour π† ° d ONLN dO]i )Ece data ° d ONLN dWi äu ï (r ästr fi ° d ONLN dZi ïu ¨ ) uctur c‡ ° d ONLN d_i ≠u › ) e in the car y‡ ° d ONLN dki ›u Î )0d fi "` ° d ONLN doi Ïu
)rmwar ° d ONLN dti
u\ ) e has a unique ID. ≈ ° d ONLN dái[u| )QApple r ᆠ° d ONLN déi}u )" eserves ID numbers in the range ° d ONLN dÆu äÅ Ë (~ ä$00 – $EF for sResour ° d ONLN d√u ÈÅ )_ ce data str ° d ONLN dŒuÅ- )-uctur ñ ° d ONLN d”u-ÅI )es defi ¿ ° d ONLN d⁄uJÅ„ ) #ned for all declaration ROMs; at pr ∫ ° d ONLN d˝u„Å )ô
° d ONLN d \ l h à ( e lThe of WÄ ° d ONLN d \ à h † ) fset fi Å ° d ONLN d
\ † h) ) eld of each entry contains an of ‡ ° d ONLN d - \) hÏ )â.fset (counting only bytes accessible by valid ° d ONLN d [ h l t › ( q lbyte lanes) to the sResour Ä ° d ONLN d u h › t
)q ce data str uÄ ° d ONLN d Ä h
t! )-uctur ˚` ° d ONLN d Ö h! tD )e. The fi
Ä ° d ONLN d é hE t^ )$nal of „ ° d ONLN d î h] tu )fset fi † ° d ONLN d õ hv tÏ )eld must have a value of 0.
í * ô¯ 4 ì * ô¯ î l î¯
ˇ·ˇ‚7^
° d ONLN d ∑ Ö l ì ñ ( è lsResour ΩÄ ° d ONLN d æ Ö ñ ì œ )* ce Data Str › ° d ONLN d … Ö œ ì Î )9uctur @ ° d ONLN d Œ Ö Ï ì ˆ ) es ˇˇˇˇˇˇ ( èÚ3
° d ONLN d — ô l • ´ ( ¢ l
Every sResour @† ° d ONLN d fi ô ¨ • Ÿ )@ ce data str 6† ° d ONLN d È ô Ÿ • )-uctur ºÄ ° d ONLN d Ó ô •7 )e contains of an ° d ONLN d ˇ ô8 •w )HsResource list ` ° d ONLN d
ôw •È )?. Each entry of an sResour û‡ ° d ONLN d' ôÈ •Ú )rce ÿ¿ ° d ONLN d) ôÚ •Ù ) ° d ONLN d* • l ±* ( Æ l+list contains information about the sResour S ° d ONLN dU •* ±ô )æce or contains a signed of l@ ° d ONLN do •ô ± )ofset to another data ° d ONLN dÑ ± l Ω w ( ∫ lstr fi ° d ONLN dá ± w Ω é ) uctur c‡ ° d ONLN då ± è Ω– )Je, which might contain icons, code, device drivers, or other information r , ° d ONLN d÷ ±— ΩÒ ( ∫—elating ° d ONLN dfi Ω l … ™ ( Δ lto the sResour HÄ ° d ONLN dÏ Ω ´ … π )?ce. ° d ONLN dÒ œ l € ¢ ( ÿ l The sResour Ô ° d ONLN d¸ œ ¢ € œ )6 ce data str  ° d ONLN d œ œ € Ê )-uctur j‡ ° d ONLN d œ Á €] )e is made up of its sResour ć ° d ONLN d' œ] €‡ )v ce list and all the information ° d ONLN dG € l Á › ( ‰ lpointed to by the sResour ∏` ° d ONLN d` € › Á )qce list entries.
Ù *¯ 4 ı * ¯
° d ONLN dˇˇ ( ¸ lNOTE
ˇ·ˇ‚7^
° d ONLN dq ˛ l
ü *
An sResour À‡ ° d ONLN d{ ˛ ü
à )3 ce data str ¡‡ ° d ONLN dÜ ˛ Ã
„ )-uctur G¿ ° d ONLN dã ˛ ‰
* )e is sometimes r —@ ° d ONLN dõ ˛*
> )Feferr p ° d ONLN d† ˛?
j ) ed to as a J@ ° d ONLN d´ ˛k
),slot r Ô@ ° d ONLN d± ˛
î )esour k‡ ° d ONLN d∂ ˛ï
ú )ce a` ° d ONLN d∏ ˛ù
¢ ). ° d ONLN d∫
l ≠ ( l
Note, however ] ° d ONLN d«
≠ „ )A, that a slot r ’` ° d ONLN d÷
„ ˚ )6esour † ° d ONLN d€
¸: )ce is a data str 9 ° d ONLN dÎ
:Q )>uctur æ‡ ° d ONLN d
Qy )
e in the fi ¨` ° d ONLN d˚
zò ))rmwar è ° d ONLN d
òü ) e ° d ONLN d l" ≠ ( lof a NuBus car ¥Ä ° d ONLN d ≠"7 )A d and not a type of Macintosh r W¿ ° d ONLN d/8"P )ãesour † ° d ONLN d4P"^ )ce. ,
Zapf Dingbats
Ÿ‡ ° d ONLN dˇˇ )u
° d ONLN dM( l4 ¢ (1 l The sResour Ô ° d ONLN dX( ¢4 » )6 ce list str ◊ ° d ONLN dc( …4 ‡ )'uctur \‡ ° d ONLN dh( ·4R )e is similar to the sResour Q ° d ONLN dÉ(R4j )qce dir ‘ ° d ONLN dâ(j4ì )
ectory str %† ° d ONLN dì(î4´ )*uctur ´Ä ° d ONLN dò(´4Ã )e. Each ° d ONLN d†4 l@ è (= lsResour ≥@ ° d ONLN dß4 è@
)# ce list entry has an 8-bit ID fi *‡ ° d ONLN d«4@^ )eld, which identifi °† ° d ONLN d⁄4^@√ )Pes the type of the entry ç ° d ONLN dÚ4¬@Ô )d , and a 24- ° d ONLN d˝@ lL Ç (I lbit of N ° d ONLN d@ ÉL õ )fset fi w¿ ° d ONLN d
fset to a lar É ° d ONLN dV@ŸLÈ )0ger ° d ONLN dZL lX √ (U lblock of data. The fi ‘‡ ° d ONLN doL √X) )Wnal entry in an sResour ¨ ° d ONLN dÜL)XÊ )f+ce must contain the value $FF in the type fi ‡ ° d ONLN d≤LÁX˜ )æeld ° d ONLN d∂X ld È (a l and the value 0 in the data fi +‡ ° d ONLN d‘X Íd ˙ )~eld. ° d ONLN dŸj lv Ñ (s lFigur R¿ ° d ONLN dfij Ñv ò )e 3-3 @ ° d ONLN d„j òv% ) shows the format of an sResour Ö‡ ° d ONLN dj&vA )éce list.
ö *´¯ 4ö *™¯ "ö *_
ˇ·ˇ‚7^
° d ONLN dˇˇ (ó l
Figure 3-4 ° d ONLN d è Æö )BsResource list structure
° d ONLN d \ ñ h ) It may contain a 24-bit of Y@ ° d ONLN d \ h- )n fset to lar [` ° d ONLN d ' \- h_ )) ger data str b‡ ° d ONLN d 3 \_ hv )2uctur Ë¿ ° d ONLN d 8 \v hÅ )es ° d ONLN d < t ä Ä ê ( } äT µ¿ ° d ONLN d = t è Ä ± )able 3-2 √@ ° d ONLN d E t ± Ä „ )" lists the lar [ ° d ONLN d S t ‰ Ä )3 ger data str b† ° d ONLN d _ t Ä- )2uctur ËÄ ° d ONLN d d t- Ä∞ )es commonly used in sResour Q¿ ° d ONLN d t± Äfi )Ñ ce data str G¿ ° d ONLN d ä tfi Äı )-uctur Õ† ° d ONLN d è tı Ä )es.
£ H ´ 4 § H ´ ß ä ß
ˇ·ˇ‚7^
° d ONLN dˇˇ ( ° ä Table 3-2 ° d ONLN d ì ô » § ˙ )> Larger Data X‡ ° d ONLN d ü ô ˙ § ˇ )2T Y∞ ° d ONLN d † ô ˇ § )ypes ° d ONLN d ¶ ± ä º • ( π äData T T∞ ° d ONLN d ¨ ± • º ¥ )ype ° d ONLN d ∞ ± Ó º )I Description ,
Courier
. ° d ONLN d Ω ø ä À ¢ ( » äLong . ° d ONLN d ¬ ø Ó Àg )d 32 bits, signed or unsigned. . ° d ONLN d ‡ — ä › ¥ ( ⁄ äPointer . ° d ONLN d Ë — Ó ›g )d 32 bits, signed or unsigned. . ° d ONLN d „ ä Ô ¥ ( Ï äcString . ° d ONLN d „ Ó Ô» )d0One-dimensional array of bytes, ending with $00. . ° d ONLN d@ ı ä Æ ( ˛ äsBlock . ° d ONLN dG ı Ó ı )dA ∫† ° d ONLN dH ı ı` ) sized block of data. See $¿ ° d ONLN db ıay )lFigur ˜Ä ° d ONLN dg ıxå )e 3-5 ï ° d ONLN dl ıçè ). . ° d ONLN do ä Δ ( ä
SExecBlock . ° d ONLN dz Ó ı )dA ∫† ° d ONLN d{ ıa ) sized block of code. See ë¿ ° d ONLN dïbz )mFigur dÄ ° d ONLN dözé )e 3-5 ° d ONLN düèë ). ˇˇÑ∞ . ° d ONLN d°* ä6 ù (3 äThe ˇ˛é ∞ ° d ONLN d•* û6 ¬ )sBlock ˇˇÑ∞ ∞ ° d ONLN d´* ¬6 ÷ )$ and ˇ˛é ° d ONLN d∞* ÷6 )
SExecBlock ˇˇÑ∞ ° d ONLN d∫*67 )< data str p ° d ONLN d√*76M )%uctur ’– ° d ONLN d»*L6™ )es begin with a size fi m@ ° d ONLN dfl*´6 )_eld, which contains the ° d ONLN d˜6 äB] (? ä0physical size of the block (including the size fi ° d ONLN d(6]Bâ )”
eld). The ° d ONLN d26âB≠ ),sBlock ° d ONLN d86≠Bª )$ str l ° d ONLN d<6ªB— )uctur >` ° d ONLN dA6—B )e follows the ° d ONLN dOB äN • (K äsize fi ° d ONLN dVB •N+ ) eld with its actual data. The ° d ONLN dtB+Ng )Ü
SExecBlock ° d ONLN d~BgNp )< fi ° d ONLN dÅBpN“ ) eld follows the size fi ° d ONLN dòB“N )beld with some . ° d ONLN d¶N äZ ¿ (W ä additional fi ܆ ° d ONLN d≥N ¿Z )6elds and code.
} Hé 4~ Hé "~ H_
ˇ·ˇ‚7^
° d ONLN dˇˇ ({ ä
Figure 3-5 ° d ONLN d√s Ã~† )B3Format of the sBlock and SExecBlock data structures
0 H7 41 H7 2 ä2
ˇ·ˇ‚7^
° d ONLN d˜# ä1 ¥ (- äsResour ΩÄ ° d ONLN d˛# ¥1 … )*ce T @ ° d ONLN d# …1& )ypes and sResour Y¿ ° d ONLN d#&1Y )]ce Names ˇˇˇˇˇˇ )Í3
. ° d ONLN d= äI · (F äThe Slot Manager r R` ° d ONLN d-= ·I ¯ )Wequir $¿ ° d ONLN d2= ¯IT )es that each sResour ˜ ° d ONLN dF=SI† )[ce list contain an ˜ ° d ONLN dY=†I÷ )M sRsrcType ˜ ° d ONLN db=÷I )6 entry €` ° d ONLN dh=ÔI ), which ° d ONLN dpI äU ≠ (R äidentifi ° d ONLN dxI ≠U )#es the . ° d ONLN dI U ) sResource type . ° d ONLN dçIU4 )E , and an ° d ONLN dñI4Uj )% sRsrcName ° d ONLN düIjUÑ )6 entry ˙` ° d ONLN d•IÇU± )
, which pr ÿ ° d ONLN dØI±U„ )/ ovides the . ÿ ° d ONLN d∫I„U )2
sResource ° d ONLN dƒU äa ¢ (^ äname ` ° d ONLN d»U £a • ). . ° d ONLN d g äs û (p äThe ° d ONLN dŒg ûs ‘ ) sRsrcType ° d ONLN d◊g ‘s- )6 entry contains an of R` ° d ONLN dÏg-sX )Y fset to an . R` ° d ONLN d˜gXsw )+sRsrcT Ñ` ° d ONLN d˝gvs¶ )
ype record . ë† ° d ONLN dg¶sº )0—a r d ° d ONLN d gºsŒ )ecor 6` ° d ONLN dgŒs )d containing 2 . ° d ONLN d s ä ± (| älong wor O‡ ° d ONLN d&s ≤ Ú )(ds that identifi ’` ° d ONLN d6s Ú1 )@es the sResour φ ° d ONLN dDs1R )?ce type. ° d ONLN dMÖ äë ¢ (é äFigur R¿ ° d ONLN dRÖ ¢ë ∂ )e 3-6 @ ° d ONLN dWÖ ∂ë> ) shows the format of an sRrscT @ ° d ONLN duÖ>ëT )àype r ∏ ° d ONLN dzÖTëf )ecor ,Ä ° d ONLN d~Ögëo )d.
° d ONLN d › l È î *Category ° d ONLN d % › » È4 )\The most general classifi ° d ONLN d > ›5 Èk )m
cation of car ˚† ° d ONLN d K ›j È„ )5d functions. Some example . ° d ONLN d e È » ı ( Ú »
categories ar R` ° d ONLN d r È ı ):e ,
Courier R` ° d ONLN d t È ıE )
CatDisplay R` ° d ONLN d ~ ÈE ıZ )< and R` ° d ONLN d É ÈZ ıñ )
CatNetwork R` ° d ONLN d ç Èñ ıô )<. . ° d ONLN d è ¯ l v ( lcT + ° d ONLN d ë ¯ v Ü )
ype ˇˇ˙ . ° d ONLN d ï ¯ »E )R The subclass of the category LH ° d ONLN d ± ¯ET )}. W π™ ° d ONLN d ¥ ¯T )
ithin the ˇˇÓ ≠Æ ° d ONLN d æ ¯Äº ),
CatDisplay ˇˇ˙ ≠Æ ° d ONLN d » ¯º‰ )< category ã ° d ONLN d — ¯‰˜ )(, for ° d ONLN d ◊ » (
»
example, ther R` ° d ONLN d ‰! )@e is a R` ° d ONLN d Î!Q )TypVideo R` ° d ONLN d ÛQ¡ )0 subcategory; within the ° d ONLN d » ( »
CatNetwork ° d ONLN d - )< category d@ ° d ONLN d , E )(, ther 6† ° d ONLN d%E ^ )e is a 6† ° d ONLN d,^ ¶ ) TypAppleTalk 6† ° d ONLN d8¶ › )H subcategory ‡ ° d ONLN dD‹ fl )6. . ° d ONLN dF l+ Ü (( lDrSW ° d ONLN dK »+ )\The driver softwar ˘¿ ° d ONLN d] +õ )R e interface of the subcategory b‡ ° d ONLN d{ õ+€ )Å. For example, ° d ONLN dä+ »7¶ (4 »0under the category Display and the subcategory V 1 ° d ONLN d∫+¶7– )fi
ideo, ther ¿ ° d ONLN dƒ+–7Ë )*e is a ˇ˛ôÄ . ° d ONLN dÀ7 »C ˛ (@ » DrSWApple ˇˇàÄ ° d ONLN d‘7 ˛C" )6 softwar ⁄‡ ° d ONLN d‹7"C≤ )$!e interface, which indicates the ' ° d ONLN d˝7≥C„ )ë Apple-def ˜Ä ° d ONLN d7‚C˜ )/ined . ° d ONLN d C »Ofi (L »;interface to work with QuickDraw using Macintosh Operating ° d ONLN dFO »[ * System frame buf ° d ONLN dVO[( )Nfers. ° d ONLN d\^ lj ä (g lDrHW ° d ONLN da^ »j ˚ )\ The identifi í` ° d ONLN dm^ ˚jP )3cation of the specifi ° d ONLN dÇ^Qjf )Vc har è¿ ° d ONLN dá^fj} )dwar «Ä ° d ONLN dã^}jÍ )e device associated with ° d ONLN d§j »v (s »the driver softwar ` ° d ONLN d∂jvJ )P
e interface. ° d ONLN dƒÇ lé œ (ã lThe value of each sRsr \¿ ° d ONLN d⁄Ç œé Ÿ )ccT ¿ ° d ONLN d‹Ç Ÿé{ )
$ype entry is unique and assigned by fl† ° d ONLN d ÇzéŒ )°Apple Developer T •‡ ° d ONLN dÇŒéÙ )T echnical ° d ONLN dé lö ì (ó l support. ° d ONLN d$† l¨ í *The sRsr ®¿ ° d ONLN d,† í¨ )&cName entry contains an of ¬ ° d ONLN dF† ¨r )yfset to a cString data str Ä¿ ° d ONLN d`†s¨ä )huctur † ° d ONLN de†ã¨‘ )e containing the ° d ONLN dv¨ l∏ ∏ (µ lsResource name. ñ¿ ° d ONLN dÖ¨ ∏∏" )L By convention, the sRsr ˆ ° d ONLN dù¨"∏I )jcName fi flÄ ° d ONLN d•¨J∏€ )("eld is derived by stripping the pr Å` ° d ONLN d«¨‹∏Ê )íefi W¿ ° d ONLN d ¨Á∏˜ ) xes ° d ONLN dŒ∏ lƒ s (¡ lfr ò‡ ° d ONLN d–∏ sƒ ß ) om the sRsr ¨¿ ° d ONLN d€∏ ߃ ± )4cT W¿ ° d ONLN d›∏ ±ƒ= )
ype values and separating the fi ,‡ ° d ONLN d˝∏>ƒå )çelds by underscor ʆ ° d ONLN d∏åƒÊ )Nes. For example, the ° d ONLN d#ƒ l– (Õ lsRsr m ° d ONLN d'ƒ – ‡ )cName for an sResour
` ° d ONLN d;ƒ ·– )b
ce whose sRsr ’¿ ° d ONLN dHƒ –( )=cT Ä¿ ° d ONLN dJƒ(–b )
ype values ar = ° d ONLN dWƒc–õ ); e CatDisplay Ä ° d ONLN dcƒõ–¶ )8, T [@ ° d ONLN dfƒ•–∑ )
ovides information about these ° d ONLN dˇÓ l˙ Õ (˜ land other entry types.
* ¯ 4 * ¯ l¯
ˇ·ˇ‚7^
° d ONLN d l õ * The Boar ¸ ° d ONLN d õ œ )/ d sResour é ° d ONLN d' – € )5ce ˇˇˇˇˇˇ (Ú3
° d ONLN d* l+ ì (( lThe Boar ° d ONLN d2 î+ ø )( d sResour · ° d ONLN d; ø+ )+ce is a special sResour Ω@ ° d ONLN dR +M )a ce data str ≥@ ° d ONLN d] M+d )-uctur 9 ° d ONLN db e+Ø )e that must be pr À¿ ° d ONLN ds Ø+„ )J
7NCf )Lce dir j` ° d ONLN d7gCÇ )ectory ¬ ° d ONLN d7ÅCÉ ). ° d ONLN dI lU œ (R lThe entries in the Boar Ë ° d ONLN d/I œU ˙ )c d sResour ∑ ° d ONLN d8I ˚U ),
ce list pr @ ° d ONLN dBI!Uµ )&!ovide the Slot Manager with a car …Ä ° d ONLN dcIµUƒ )îd’s ° d ONLN dgU la ã (^ lidentifi V† ° d ONLN doU åa à )
cation number ÎÄ ° d ONLN d|U Àa? )?, vendor information, boar Æ ° d ONLN dñU@aN )ud fl V† ° d ONLN döUOaÌ )'ags, and initialization code. Like all . ° d ONLN d¡a lm é (j lsResour R` ° d ONLN d»a ém Ω )" ce data str >` ° d ONLN d”a Ωm ” )/uctur ¿ ° d ONLN dÿa ”m ) es, the Boar „ ° d ONLN d‰am2 )5 d sResour µÄ ° d ONLN dÌa2mñ )*ce list must include an µÄ ° d ONLN dañmà )d sRsrcType µÄ ° d ONLN daÃmË )6 entry . ° d ONLN dm ly ü (v l and an sRsr +Ä ° d ONLN d m †y Ÿ )4 cName entry K† ° d ONLN d+m ÿy )8
. The Boar ›† ° d ONLN d5my ),d sRsr f` ° d ONLN d;m y* ) cT ` ° d ONLN d=m*yœ )
%ype entry must contain the constants . ° d ONLN dby lÖ ú (Ç lCatBoard ° d ONLN djy úÖ ≈ )0
($0001), ° d ONLN dty ≈Ö ı ))TypBoard ° d ONLN d|y ıÖ )0
($0000), ° d ONLN dÜy ÖT )) DrSWBoard ° d ONLN dèyTÖê )6 ($0000), and ° d ONLN dùyêÖΔ )< DrHWBoard ° d ONLN d¶yΔÖÔ )6
. ° d ONLN d \ ä h ¥ ( e äThe Boar R` ° d ONLN d \ ¥ h fi )* d sResour $¿ ° d ONLN d \ fi hR )* ce list must also contain a ,
Courier $¿ ° d ONLN d - \R h| )tBoardId $¿ ° d ONLN d 4 \| hñ )* entry ° d ONLN d : \ï h≥ ), a wor €` ° d ONLN d A \≤ h
) d that contains the . ° d ONLN d U h ä t ó ( q äcar µ@ ° d ONLN d X h ó t fl )
d design identifi ‡ ° d ONLN d i h ‡ tY )Ication number assigned by E¿ ° d ONLN d É hY tfi )yApple Macintosh Developer T ÒÄ ° d ONLN d û h› t )Ñ echnical ° d ONLN d ß t ä Ä œ ( } äSupport. Other C ° d ONLN d ∂ t œ Ä ˛ )E Apple-defi † ° d ONLN d ¿ t ˇ ÄN )0ned entries specifi ÍÄ ° d ONLN d ” tN Äâ )Ocally for Boar Ç ° d ONLN d · tâ Ä¥ ); d sResour õ‡ ° d ONLN d Í tµ Ä‚ ), ce data str ë‡ ° d ONLN d ı t‚ Ģ )-uctur ¿ ° d ONLN d ˙ t˙ Ä )es ar c` ° d ONLN d ˇ t Ä )e ° d ONLN d Ä ä å ¬ ( â ä
discussed in Q† ° d ONLN d Ä √ å£ )94Designing Cards and Drivers for the Macintosh Family à¿ ° d ONLN dB Ä¢ å§ )fl. . ° d ONLN dD ò ä § ¢ ( ° äFigur R` ° d ONLN dI ò ¢ § ∑ )e 3-7 R` ° d ONLN dN ò ∑ § ) shows a sample Boar $¿ ° d ONLN db ò §B )a d sResour ˜ ° d ONLN dk òA §Ñ ))ce. It shows an ˜ ° d ONLN d{ òÑ §∫ )C sRsrcType ˜ ° d ONLN dÑ ò∫ §œ )6 and ˜ ° d ONLN dâ òœ § ) sRsrcName ˜ ° d ONLN dí ò § )6 ° d ONLN dì § ä ∞ ( ≠ äentry and also includes thr R` ° d ONLN dÆ § ∞F )xee entry types, R` ° d ONLN dæ §F ∞p )DBoardID R` ° d ONLN d≈ §p ∞u )*, R` ° d ONLN d« §u ∞Ω ) PRAMInitData R` ° d ONLN d” §Ω ∞’ )H, and ° d ONLN dŸ ∞ ä º à ( π ä PrimaryInit ° d ONLN d‰ ∞ à º Ú )B , that ar R` ° d ONLN dÌ ∞ Ú º0 )&e discussed in . R` ° d ONLN d¸ ∞0 º )>4Designing Cards and Drivers for the Macintosh Family . âÄ ° d ONLN d0 ∞ º )fl.
ˇˇ£‰ ˇÆ ° d ONLN dI. H@ ˝ (< HAbout the Slot Manager ˇˇˇˇˇˇ ⁄| (< 3
° d ONLN d`Q ä] ‰ (Z äThe Slot Manager pr Ù‡ ° d ONLN dsQ ‰] )Z
ovides thr t ° d ONLN d}Q][ )-ee basic services: ,
Zapf Dingbats
° d ONLN dêf äm è (l än
° d ONLN díc ñoÓ ) OAt system startup time, it examines each slot and initializes any expansion car k¿ ° d ONLN d·cÓo (lÓds it ° d ONLN dÁo ñ{ ú (x ñfi å¿ ° d ONLN dÈo ú{ Æ )nds.
ÅçÛ )6es that contain information about each slot and every ° d ONLN d@ç ñô „ (ñ ñavailable sResour „‡ ° d ONLN dQç „ô )M ce data str Ÿ‡ ° d ONLN d\çô' )-uctur _¿ ° d ONLN daç(ô/ )e.
° d ONLN d \ l h Ä ( e lTher ¿ ° d ONLN d \ Å h ë )e ar ` ° d ONLN d \ ë h9 )&e two variations of the system softwar ` ° d ONLN d . \9 h )®*e version 7.0 Slot Manager: version 1 and ° d ONLN d X h l t † ( q l version 2. V Î ° d ONLN d d h ü t¡ )3Bersion 1 of Slot Manager is supplied with the version 7.0 System fi Í¿ ° d ONLN d ß h¬ tÔ ( q¬ le on disk ° d ONLN d ≤ t l Äõ ( } lCfor use with Macintosh II-family computers designed and built befor ÿ‡ ° d ONLN d ı tõ Ä‘ ( }õ
e the system ° d ONLN d Ä l å ç ( â lsoftwar ‰¿ ° d ONLN d Ä ç å )! e version 7.0 was available. V ^ ° d ONLN d' Ä åˆ )Å3ersion 2 is included in the ROM of newer Macintosh ° d ONLN dZ å l ò Δ ( ï lII-family computers. ° d ONLN do û l ™d *6When the user starts up a Macintosh II-family computer « ° d ONLN d• ûc ™Ù )˜", the version of the Slot Manager ° d ONLN d« ™ l ∂ £ ( ≥ l in ROM sear Ä ° d ONLN d“ ™ § ∂c )8+ches each slot for a declaration ROM and cr µ ° d ONLN d˝ ™c ∂Ä )øeates a G† ° d ONLN d ™Å ∂Ì ) slot information record M` ° d ONLN d ™Ì ∂Ô )l ° d ONLN d ∂ l ¬ò ( ø lCfor each slot. The section “Getting Information about Expansion Car Ÿ` ° d ONLN d` ∂ò ¬Ó ( øòds and Declaration ˇˇx . ° d ONLN ds ¬ l Œ í ( À lROMs” r l ° d ONLN dz ¬ í Œ § )&efer úà ° d ONLN d~ ¬ § Œ7 )#ence section, later in this chapter 7® ° d ONLN d° ¬7 Œ| )ì, shows the defi üà ° d ONLN d± ¬| Œ¥ )Enition of the ,
Courier ˇ˛h$ ° d ONLN dø ¬µ Œ˜ )9 SInfoRecord ˇˇx ° d ONLN d ¬˜ Œ¯ )B . ° d ONLN dÀ Œ l ⁄ ó ( ◊ l
ess NuBus car %‡ ° d ONLN dJ ˝T £ )?ds in 24-bit mode ° d ONLN d\ l ( l(and may not be able to identify some car ŒÄ ° d ONLN dÑ . )≥ds. »‡ ° d ONLN dà .° ) After version 1 of the Slot ° d ONLN d§ l! ( l'Manager is loaded, it locates these car qÄ ° d ONLN dÀ!" )ßds. ,
Zapf Dingbats
@ ° d ONLN dˇˇ )u
° d ONLN d‰' l3 ⁄ (0 lAs the Slot Manager sear ü@ ° d ONLN d¸' ⁄3A )nches the slots, it identifi `Ä ° d ONLN d'B3ô )hes all of the sResour ‡ ° d ONLN d,'ö3« )X ce data str ‡ ° d ONLN d7'«3fi )-uctur ç¿ ° d ONLN d<'fi3Ù )es in ° d ONLN dB3 l? Ï (< leach declaration ROM and cr O ° d ONLN d]3 Ì?< )Åeates a table—the ; ° d ONLN do3=?Ñ )PSlot Resource T ƒÄ ° d ONLN d~3É?ñ )Fable 4 ° d ONLN dÇ3ó?ß ), or @ ° d ONLN dá3®?µ )SR „Ä ° d ONLN dâ3¥?∫ ) T è ° d ONLN dä3ª?Ï ) —that lists ° d ONLN dñ? lK ∏ (H lall of the sResour ™¿ ° d ONLN d®? ∏K  )L ce data str †¿ ° d ONLN d≥? ÂK ¸ )-uctur &† ° d ONLN d∏? ˝K )es curr ‹@ ° d ONLN dø?Kú ) ently available to the system. ° d ONLN dflQ l]á (Z l?The Slot Manager then initializes the six parameter RAM bytes r Ã` ° d ONLN d Qá]Ô (Záeserved for each slot. If . ° d ONLN d8] li Ó (f l the slot has an expansion car R` ° d ONLN dU] Ói )Ç d with a R` ° d ONLN d^]i_ )) PRAMInitData R` ° d ONLN dj]_i™ )H entry in its Boar $¿ ° d ONLN d|]™i‘ )K d sResour ˜ ° d ONLN dÖ]”iÛ ))ce, the . ° d ONLN dçi luÚ (r lZSlot Manager uses the values in that entry to initialize the parameter RAM; otherwise, it ° d ONLN dÁu lÅ * %clears the parameter RAM bytes to 0. ° d ONLN d
á lì™ *HAfter the parameter RAM initialization, the Slot Manager disables interr † ° d ONLN dUá™ì” (ê™ upts and . ° d ONLN d^ì lü ÿ (ú lexecutes the code in the ° d ONLN dwì ÿü )l PrimaryInit ° d ONLN dÇìüg )B entry of each car R` ° d ONLN dîìgüå )Md’s Boar $¿ ° d ONLN dúìåü∂ )% d sResour ˜ ° d ONLN d•ìµü√ ))ce. . ° d ONLN d™• l± … (Æ lIf certain values (defi Ω` ° d ONLN d¡• …±G )] ned by the Start Manager) ar J@ ° d ONLN d›•H±~ )e set in a car K‡ ° d ONLN dΕ~±Ô )6d’s parameter RAM, a car ú† ° d ONLN d•Ô±˜ )qd . ° d ONLN d± lΩ í (∫ lwith an ° d ONLN d
± íΩ ⁄ )& sRsrcBootRec ° d ONLN d± ⁄Ωô )H* entry may take over the system startup pr R` ° d ONLN dC±ôΩÈ )øocess. The system . ° d ONLN dUΩ l… ú (Δ l gives contr ‚‡ ° d ONLN d`Ω ú…¨ )0Aol to the code in this entry early in the startup sequence, befor W ° d ONLN d°Ω≠…Ê (Δ≠
e the system ° d ONLN dÆ… l’ ò (“ l
patches ar Q¿ ° d ONLN d∏… ô’ ¡ )- e loaded. ° d ONLN d¬€ lÁL (‰ l4Designing Cards and Drivers for the Macintosh Family . “‡ ° d ONLN dˆ€LÁã )‡ describes the “‡ ° d ONLN d€ãÁ” )? PRAMInitData “‡ ° d ONLN d€”Áÿ )H, ° d ONLN dÁ lÛ Æ ( l PrimaryInit ° d ONLN d Á ÆÛ Δ )B, and ° d ONLN d$Á ΔÛ ) sRsrcBootRec ° d ONLN d0ÁÛF )H
entry types. . ° d ONLN d>˘ l ê ( l If no car ÆÄ ° d ONLN dG˘ ê ≈ )$ d takes over Ω ° d ONLN dS˘ ≈p )5', the normal system startup continues. ô† ° d ONLN dz˘p„ )´ After version 1 of the Slot ° d ONLN dñ l0 ( l,Manager is loaded, it conducts a second sear /‡ ° d ONLN d¬1Ú )≈-ch for declaration ROMs, this time in 32-bit ° d ONLN dÔ l ¢ ( l
mode. If it fi ò¿ ° d ONLN d˝ ¢ )6nds any new NuBus car Ä ° d ONLN d v )jds, it adds their sResour d ° d ONLN d +v £ )j ce data str Z ° d ONLN d 6£ ∫ )-uctur ‡ ° d ONLN d ;∫ Ù )es to the Slot . ° d ONLN d J l) ä (& lResour R` ° d ONLN d P ä) õ ) ce T g` ° d ONLN d T ö)7 )$able and executes the code in their g` ° d ONLN d x 7)y )ù PrimaryInit g` ° d ONLN d É y)´ )B entries. (V K† ° d ONLN d è ™)Î )1ersion 2 of the . ° d ONLN d ü) l5 ¶ (2 l Slot Manager ¥† ° d ONLN d ´) ¶5 à ): , which r L ° d ONLN d ¥) Õ5ø )'5esides in ROM, does not need to conduct a second sear !` ° d ONLN d È)ø5œ )Úch.) ° d ONLN d Ó; lGÿ (D lUAfter all system patches have been installed, version 1 or later of the Slot Manager . ° d ONLN d
CG lS Ÿ * executes the code in any ° d ONLN d
\G ŸS' )m
SecondaryInit ° d ONLN d
iG'S[ )N
entries it fi ° d ONLN d
wG[SÎ )4 nds in the declaration ROMs. It ° d ONLN d
óS l_ ñ (\ l
does not r R` ° d ONLN d
°S ñ_ Ó )*eexecute the code fr $¿ ° d ONLN d
µS Ó_ ˝ )Xom $¿ ° d ONLN d
∏S ˝_? ) PrimaryInit $¿ ° d ONLN d
√S?_i )B entries, r ˜ ° d ONLN d
ŒSh_ˆ )) einitialize parameter RAM, or ° d ONLN d
Ï_ lk p (h lr R` ° d ONLN d
Ì_ pk Ü )estor $¿ ° d ONLN d
Ú_ Ük ¬ )
e any sResour ˜ ° d ONLN d
ˇ_ ¡k ); ce data str „ ° d ONLN d
_ k )/uctur µÄ ° d ONLN d _kU )es deleted by the µÄ ° d ONLN d !_Ukó )O PrimaryInit µÄ ° d ONLN d ,_ók≤ )B code.
y *Ö¯ 4y *Ö¯
. ° d ONLN dˇˇ (Ä lNOTE
ˇ·ˇ‚7^
° d ONLN d 4É lè s * V ú` ° d ONLN d 5É rèè )Bersions of the Slot Manager earlier than version 1 do not execute . ° d ONLN d wè lõ ä (ò lcode fr R` ° d ONLN d ~è äõ ô ) om R` ° d ONLN d Åè ôõ Á )
SecondaryInit R` ° d ONLN d éè Áõ
)N
entries.
. R` ° d ONLN dˇˇ ))u
. ° d ONLN d ≠° l≠ ˇ (™ l After the Slot Manager executes ° d ONLN d Õ° ˇ≠M )ì
SecondaryInit ° d ONLN d ⁄°M≠Ö )N code, it sear R` ° d ONLN d Ë°Ö≠à )8ches for sResour $¿ ° d ONLN d ¯°Ã≠Ô )Gce data ˇˇ›® ° d ONLN d ≠ lπ x (∂ lstr l ° d ONLN d ≠ xπ é ) uctur >` ° d ONLN d ≠ éπ ÷ )es that have an ˇˇò¯ µ ° d ONLN d ≠ ÷π )H
e with this fl å ° d ONLN d ; \å h¸ )7 ag set, it loads the device . ° d ONLN d W h ä t ± ( q ä driver fr R` ° d ONLN d ` h ± t “ )'om the ,
Courier R` ° d ONLN d g h “ t )! sRsrcDrvrDir R` ° d ONLN d s h tu )H entry of the sResour $¿ ° d ONLN d à hu t˚ )[ ce, or calls the code in sResour ˜ ° d ONLN d ® h˙ t )Öce’s ° d ONLN d ≠ t ä Ä “ ( } ä sRsrcLoadRec ° d ONLN d π t “ Ä Ï )H entry d@ ° d ONLN d ø t Î Ä_ ), which loads the sResour 6† ° d ONLN d ÿ t_ ÄÆ )tce’s device driver y@ ° d ONLN d Í t≠ Ä∞ )N. ° d ONLN d Ï Ü ä í ≠ ( è äFinally d@ ° d ONLN d Û Ü ¨ íQ )"&, the system executes initialization ( d@ ° d ONLN d ÜQ íu )•'INIT' d@ ° d ONLN d Üu í )$) r 6† ° d ONLN d" Ü íñ )
esour ° d ONLN d' Üñ í¶ )ces. . ° d ONLN d, ò ä § õ ( ° äSee ” ° d ONLN d0 ò õ §{ )4Designing Cards and Drivers for the Macintosh Family %‡ ° d ONLN dd ò| §Ÿ )· for details about the . ° d ONLN d{ § ä ∞ Δ ( ≠ ä
sRsrcFlags ° d ONLN dÖ § Δ ∞ À )<, ° d ONLN dá § À ∞ ) sRsrcDrvrDir ¬† ° d ONLN dì § ∞* )G, and ¬† ° d ONLN dô §* ∞r ) sRsrcLoadRec ¬† ° d ONLN d• §r ∞™ )H
entry types.
µ H – 4 ∂ H –
· H È 4 ‚ H È ‚ H ‚
ˇ·ˇ‚7^
ˇˇ£‰ . ˇÆ ° d ONLN d≥ Œ H ‡ ¸ ( ‹ HUsing the Slot Manager ˇˇˇˇˇˇ ⁄| ( ‹ 3
° d ONLN d Ò ä ˝ ( ˙ ä The majority of Slot Manager r ‡ ° d ONLN dË Ò ˝F )à outines sear ”‡ ° d ONLN dÙ ÒF ˝Ö )4ch for sResour ¿ ° d ONLN d ÒÜ ˝≥ )@ ce data str ˙¿ ° d ONLN d
able or pr Œ¿ ° d ONLN d5 ˝ ‰ = )*ovide information fr åÄ ° d ONLN dI ˝> s )Z om these str ° d ONLN dU ˝t ã )6uctur ù‡ ° d ONLN dZ ˝ã ô )es. ° d ONLN d_ ä ‰ ( äThe Slot Manager pr Ù‡ ° d ONLN dr ‰r )Z ovides a variety of methods to fi E` ° d ONLN dìs≤ )è
i )B . ° d ONLN d}i äu º (r ä functions, r ê@ ° d ONLN dâi ºuY )2%eturn one particular type of data str Ä ° d ONLN dÆiZuq )ûuctur í` ° d ONLN d≥iquŸ )e. Some others, like the . ° d ONLN dÃu äÅ Ã (~ ä SFindStruct ° d ONLN d◊u ÃÅ )B function, can r R` ° d ONLN dÁu ÅØ )@$eturn information about any data str >` ° d ONLN d uØÅ≈ )£uctur ¿ ° d ONLN du≈Å )e. Still other ° d ONLN d Å äç … (ä äfunctions, the ° d ONLN d.Å …ç )?
e but also pr ´‡ ° d ONLN dñç(ô€ )6(eform functions like loading the sResour Õ` ° d ONLN dæç€ô¸ )≥ce data . ° d ONLN dΔô ä• ñ (¢ ästr l ° d ONLN d…ô ñ• ¨ ) uctur >` ° d ONLN dŒô ¨•P )'e’s driver or executing the code of an >` ° d ONLN dıôP•å )§
SExecBlock >` ° d ONLN dˇôå•≤ )< data str *` ° d ONLN dô≤•» )&uctur ¸¿ ° d ONLN d
ô«•œ )e. . ° d ONLN d´ ä∑ ⁄ (¥ äIn addition to sear D‡ ° d ONLN d#´ €∑( )Qching for sResour æ† ° d ONLN d4´(∑U )M ce data str ¥† ° d ONLN d?´U∑l )-uctur :Ä ° d ONLN dD´m∑ )"es and getting information out of ° d ONLN df∑ ä√¥ (¿ äAthem, the Slot Manager allows you to enable and disable NuBus car F@ ° d ONLN dß∑µ√ (¿µds, manipulate the ° d ONLN d∫√ äœ º (à ä Slot Resour ÷@ ° d ONLN d≈√ ºœ Õ )2ce T ≈‡ ° d ONLN d…√ Õœ2 )able, get information fr n‡ ° d ONLN d·√3œë )fom slot information r ñ ° d ONLN dˆ√뜣 )^ecor
` ° d ONLN d˙√§œfl )ds, get status ° d ONLN d œ ä€ € (ÿ äinformation, and r mÄ ° d ONLN dœ €€_ )Q ead and change expansion car ° d ONLN d7œ`€∫ )Öds’ parameter RAM.
H 4 H ä
ˇ·ˇ‚7^
ˇˇ◊ ˇ◊ ° d ONLN dJ˙ ä ~ ( ä Enabling and Disabling NuBus Car ß ° d ONLN dj˙~ é )Ùds ˇˇˇˇˇˇ ® )ê3
° d ONLN dm ä ë ( äV ú` ° d ONLN dn ê )Tersion 1 and later of the Slot Manager allows you to temporarily disable your NuBus ° d ONLN d¬ ä) ó (& äcar µ@ ° d ONLN d≈ ó) ¢ )
d. £` ° d ONLN d» ¢) ® ) Y c‡ ° d ONLN d… ®)y )0ou might want to do this, for example, if you ar p ° d ONLN d˘ y)‰ )—e designing a NuBus car Ÿ ° d ONLN d ‰) )kd that ° d ONLN d) ä5 ƒ (2 ä must be addr (@ ° d ONLN d#) ≈5E ); essed in 32-bit mode or that r √` ° d ONLN dA)E5\ )Äequir ⁄† ° d ONLN dF)\5· )es RAM-based system softwar óÄ ° d ONLN da)‚5
code can ° d ONLN dæA äM Œ (J ädisable the car R` ° d ONLN dÕA ŒM5 )Dd temporarily and the R` ° d ONLN d„A5MÉ )g
SecondaryInit R` ° d ONLN dAÉM∞ )N code can r $¿ ° d ONLN d˚A∞M‚ )- eenable it. ° d ONLN d S ä_ ê (\ äT ï ° d ONLN d S è_ )o disable a NuBus car g` ° d ONLN d S _0 )a
d temporarily K† ° d ONLN d +S/_å )?, the initialization r ° d ONLN d ASå_À )]outine in your ° d ONLN d PSÀ_
)? PrimaryInit ° d ONLN d [S
_ )B ° d ONLN d \_ äk é (h är R` ° d ONLN d ]_ ék † )ecor $¿ ° d ONLN d a_ †k Õ )
d should r ˜ ° d ONLN d k_ Ãk ),
eturn in the ˜ ° d ONLN d x_k2 )6seStatus ˜ ° d ONLN d Ä_2k; )0 fi ˜ ° d ONLN d É_;ki ) eld of the ˜ ° d ONLN d é_ikì ).SEBlock ˜ ° d ONLN d ï_ìkπ )* data str „ ° d ONLN d û_πkœ )&uctur µÄ ° d ONLN d £_œk )e (described in . ° d ONLN d ≥k äw= (t ä&“Loading Drivers and Executing Code fr ∂ ° d ONLN d Ÿk=wq )≥
om sResour ≤‡ ° d ONLN d „kqw† )4 ce Data Str M ° d ONLN d Ók°w∏ )0uctur ” ° d ONLN d Ûk∏wˆ )es” on page 3- O@ ° d ONLN d
k˜w )?53 O@ ° d ONLN d
kw )
) an . ° d ONLN d
w äÉ ó (Ä äerr R` ° d ONLN d
w óÉ- )
"or code with a value in the range R` ° d ONLN d
-w-É{ )ñ
svTempDisable R` ° d ONLN d
:w{É∞ )N ($8000) thr $¿ ° d ONLN d
Fw∞É» )5ough $¿ ° d ONLN d
Kwȃ )
svDisabled $¿ ° d ONLN d
UwÉ )< ° d ONLN d
VÉ äèk (å ä2($8080). The Slot Manager places this code in the ° d ONLN d
àÉkèπ )·
siInitStatusV ° d ONLN d
ïÉπè¬ )N fi ° d ONLN d
òɬè ) eld of the slot . ° d ONLN d
®è äõ ≈ (ò ä
information r Ä` ° d ONLN d
µè ≈õ ◊ );ecor Ù¿ ° d ONLN d
πè ◊õ )Hd that the Slot Manager maintains for the slot, and it places the fatal . ° d ONLN d õ äß ó (§ äerr R` ° d ONLN d õ óß ¢ )
or R` ° d ONLN d õ ¢ß ˆ ) smInitStatVErr R` ° d ONLN d õ ˆß3 )T (–355) in the R` ° d ONLN d $õ3ßu )= initStatusA ≈¿ ° d ONLN d /õtß} )A fi ≈¿ ° d ONLN d 2õ}ß« ) eld of the sInfo r ò ° d ONLN d Dõ«ßŸ )Jecor jÄ ° d ONLN d HõŸß )
d. The car <‡ ° d ONLN d Rõß )-d . ° d ONLN d Tß ä≥ Õ (∞ äand its sResour ° d ONLN d cß Œ≥ ˚ )D ce data str ˛ ° d ONLN d nß ˙≥ ),uctur Ñ ° d ONLN d sß≥& )es ar œ† ° d ONLN d xß&≥
)3e then unavailable for use by the Operating System. ˇ%» @ ˇ ˇˇˇˇ @
° d ONLN d \ l h˜ ( e lWAfter the Operating System loads RAM patches, the Slot Manager checks the value of the ,
Courier ˇˇg‰ . ° d ONLN d W h l t ∫ *
siInitStatusA ˇˇÕL Û` ° d ONLN d d h π t æ )M f ë, ° d ONLN d f h ø t$ )ield. If this value is gr f ° d ONLN d h$ tŸ )e+eater than or equal to 0, indicating no err ¢» ° d ONLN d ™ hŸ t‚ )µor Âh ° d ONLN d ¨ h· t˜ ), the ° d ONLN d ≤ t l Ä ‰ ( } lSlot Manager executes the ° d ONLN d à t ‰ Ä2 )x
SecondaryInit ° d ONLN d Ÿ t2 Ä¢ )N code. If the value in the ° d ONLN d Ù t¢ Ä )p
siInitStatusA Û` ° d ONLN d tÔ ÄÒ )M ° d ONLN d Ä l å s ( â lfi ° d ONLN d Ä s å é )eld is ° d ONLN d Ä é å ‹ )
smInitStatErr ¬† ° d ONLN d Ä € åc )M , the Slot Manager checks the ¬† ° d ONLN d6 Äc å± )à
siInitStatusV ¬† ° d ONLN dC ı å∫ )N fi ¬† ° d ONLN dF Ä∫ åÍ ) eld. If the ° d ONLN dR å l ò • ( ï l
value of the ° d ONLN d_ å • ò Û )9
siInitStatusV ° d ONLN dl å Û ò ¸ )N fi ° d ONLN do å ¸ òO ) eld is in the range ° d ONLN dÉ åO òù )S
svTempDisable ° d ONLN dê åù òÆ )N thr R` ° d ONLN dî åÆ òΔ )ough ° d ONLN dô ò l § ® ( ° l
svDisabled ° d ONLN d£ ò ® §- )< , the Slot Manager clears the ° d ONLN d¡ ò- §{ )Ö
siInitStatusA Û` ° d ONLN dŒ òz §Ä )M f √‡ ° d ONLN d– òÄ §¨ )
ield and r ؇ ° d ONLN d⁄ ò¨ §Œ ),uns the ° d ONLN d‚ § l ∞ ∫ ( ≠ l
SecondaryInit ° d ONLN dÔ § ∫ ∞ ” )N code. ° d ONLN dˆ ∂ l ¬ µ ( ø lFor examples of ° d ONLN d ∂ µ ¬ ˜ )I PrimaryInit ° d ONLN d ∂ ˜ ¬ )B and ° d ONLN d ∂ ¬Z )
SecondaryInit ° d ONLN d# ∂Z ¬Ö )N code, see . ° d ONLN d. ∂Ö ¬› )+Designing Cards and ° d ONLN dB ¬ l Œ Û ( À l Drivers for the Macintosh Family Ä ° d ONLN db ¬ Û Œ ı )á.
Û * ˘¯ 4 Ù * ˘¯ Ù l Ù¯
ˇ·ˇ‚7^
ˇˇ◊ ˇ◊ ° d ONLN dd ‚ l ÛG ( Ô l Deleting and Restoring sResour ÿ‡ ° d ONLN dÇ ‚G Ûë )€ ce Data Str Dê ° d ONLN dç ‚í Û∑ )Kuctur ‡ ° d ONLN dí ‚∑ Û≈ )%es ˇˇˇˇˇˇ ® )93
° d ONLN dï ˘ l µ ( lSome NuBus car æ ° d ONLN d£ ˘ µ ¸ )Ids have sResour ã@ ° d ONLN d≤ ˘ ˝* )H ce data str Å@ ° d ONLN dΩ ˘*A )-uctur ° d ONLN d¬ ˘B )(es to support a variety of combinations ° d ONLN dÍ l Æ ( lof system confi ˆ` ° d ONLN d˘ Æ¿ )B=gurations or modes. The Slot Manager loads all of the sResour ° d ONLN d6¡‚ (¡ce data . ° d ONLN d> l x ( lstr l ° d ONLN dA x é ) uctur >` ° d ONLN dF é h )1es during system initialization, and then the car ¿ ° d ONLN dwh w )⁄d’s ¿ ° d ONLN d{w π ) PrimaryInit ¿ ° d ONLN dÜπ ‚ )B
code can . ° d ONLN dê l) ê (& l delete fr º@ ° d ONLN dô ê) „ )$om the Slot Resour 9` ° d ONLN d´ ‰) ı )Tce T ) ° d ONLN dØ ı)? )able any sResour ˆ` ° d ONLN dø ?)l )J ce data str Ï` ° d ONLN d l)É )-uctur r@ ° d ONLN dœ Ñ)¨ )
es that ar î ° d ONLN dŸ ¨)ƒ )(e not ° d ONLN dfl) l5 Ä (2 lappr I@ ° d ONLN d„) Å5 ) opriate for the system as confi ´@ ° d ONLN d)5 )Ñgur Ä ° d ONLN d)5¡ )'ed. If the user changes the system confi Ø ° d ONLN d-)¡5ı )¨ guration or ° d ONLN d95 lA ü (> l
selects a dif R† ° d ONLN dF5 üA ´ )3fer 5 ° d ONLN dI5 ´A; ) ent mode of operation, you can r B† ° d ONLN di5;A´ )êeinstall a deleted sResour àÄ ° d ONLN dÉ5´Aà )pce data . ° d ONLN dãA lM x (J lstr l ° d ONLN déA xM é ) uctur >` ° d ONLN dìA éM ¨ )e. The >` ° d ONLN döA ¨M ˙ )
SDeleteSRTRec >` ° d ONLN dßA ˙Mg )N function deletes sResour ¿ ° d ONLN d¿AgMñ )m ce data str ¸¿ ° d ONLN dÀAïM´ ).uctur œ ° d ONLN d–A´MÀ )es; the ° d ONLN dÿM lY ¥ (V l InsertSRTRec ° d ONLN d‰M ¥Y ‡ )H function r R` ° d ONLN dÔM ‡Y% ),einstalls them. . ° d ONLN dˇ_ lkR (h l3Because none of the Slot Manager functions can sear 6Ä ° d ONLN d2_Skí )Ách for sResour g` ° d ONLN d@_íkø )? ce data str ]` ° d ONLN dK_øk÷ )-uctur „@ ° d ONLN dP_÷kı )es that ° d ONLN dXk lw ≈ (t lhave been deleted fr Ä ° d ONLN dlk Δw )Zom the Slot Resour dž ° d ONLN d~kw* )Sce T r@ ° d ONLN dÇk*wê )able, you must keep a r ˚† ° d ONLN dôkêw¢ )fecor p ° d ONLN dùk£wÁ )d of all sResour Ÿ ° d ONLN d≠kÁwÚ )Dce ° d ONLN d∞w lÉ ç (Ä ldata str º ° d ONLN d∏w çÉ § )!uctur B ° d ONLN dΩw •Éó )7es that you have deleted so that you will have the appr 7@ ° d ONLN dÙwóÉË )Úopriate parameter ° d ONLN dÉ lè ‚ (å lvalues when you want to r S ° d ONLN d É ‚è )v
. Use the ˇˇIÍ ¢8 ° d ONLN dú≈ × )) InsertSRTRec ˇˇ√N ¢8 ° d ONLN d®≈—T )H to update the ˇˇIÍ Øp ° d ONLN d∑≈T—ñ )@ dCtlDevBase ˇˇ√N Øp ° d ONLN d¬≈ñ—û )B fi ræ ° d ONLN d≈≈ü—¯ ) eld. See the Device . ° d ONLN dŸ— l›# (⁄ l(Manager chapter of this volume for a defi -‡ ° d ONLN d—$›í )∏nition of the device contr l` ° d ONLN d —훥 )nol entry ç† ° d ONLN d$—≥›µ )!.
*¯ 4 *¯ l¯
ˇ·ˇ‚7^
ˇˇ◊ ˇ◊ ° d ONLN d&Ò lJ (˛ l Enabling and Disabling sResour Δ‡ ° d ONLN dDÒJî )fi ce Data Str 2ê ° d ONLN dOÒï∫ )Kuctur ‡ ° d ONLN dTÒ∫» )%es ˇˇˇˇˇˇ ® )63
° d ONLN dW l ∂ ( lUnder certain cir 6‡ ° d ONLN dh ∑ñ )K0cumstances, you might want to disable an sResour V‡ ° d ONLN dòñ√ )fl ce data str L‡ ° d ONLN d£√⁄ )-uctur “¿ ° d ONLN d®⁄· )e ° d ONLN d™ l ì ( l
while it r 2Ä ° d ONLN d¥ î )( emains listed in the Slot Resour È¿ ° d ONLN d‘ / )äce T Ÿ` ° d ONLN dÿ/ ∏ ) able. For example, a NuBus car Ô¿ ° d ONLN dˆ∏ › )âd might ° d ONLN d˛ l, u () lpr G ° d ONLN d v,· )
Sovide several modes of operation, only one of which can be active at a given time. ° d ONLN d S, l8 r (5 lY @Ä ° d ONLN d T, r8N )1our application might want to disable the sResour Û‡ ° d ONLN d Ö,N8{ )‹ ce data str ȇ ° d ONLN d ê,{8í )-uctur o¿ ° d ONLN d ï,ì8Ú )es associated with all ° d ONLN d ¨8 lDÓ (A l[but the active mode, but still list all available modes in a menu. When the user selects a ° d ONLN d
D lPW * 4new mode, your application can then disable the curr M† ° d ONLN d
;DXP∞ )Ïently active sResour ‡† ° d ONLN d
OD∞P— )Xce data ° d ONLN d
WP l\ w (Y lstr fi ° d ONLN d
ZP w\ é ) uctur c‡ ° d ONLN d
_P è\7 )'e and enable the one the user selected. . ° d ONLN d
áb ln s (k lY ï ° d ONLN d
àb rn † ) ou use the ï ° d ONLN d
ìb †n Ó ).
SetSRsrcState ï ° d ONLN d
†b Ónü )N) function to enable or disable an sResour g` ° d ONLN d
…bünŒ )± ce data str S` ° d ONLN d
‘bŒn‰ )/uctur %¿ ° d ONLN d
Ÿb‰nÓ )e. . ° d ONLN d
‹n lz ö (w l Listing 3-1 @ ° d ONLN d
Án õz ˜ )/ disables the sResour h† ° d ONLN d
¸n ˜z$ )\ ce data str ^† ° d ONLN d n$z; )-uctur ‰Ä ° d ONLN d n;zq )
e in slot $0A ˇ¿ ° d ONLN d nqzª )6 with an sResour ◊Ä ° d ONLN d )nªzÒ )J
ce ID of 128 ° d ONLN d 6z lÜ ÷ (É land enables the sResour ` ° d ONLN d Mz ◊Ü )k ce data str ` ° d ONLN d XzÜ )-uctur ã@ ° d ONLN d ]zÜ∏ )%e in the same slot with an ID of 131. ˇ @ ˇ ˇˇˇˇ @
° d ONLN dˇˇ ( d ä Listing 3-1 ° d ONLN d \ Œ gï )D0Disabling and Enabling sResource data structures ,
Courier
. ° d ONLN d 1 s ä ú ( | äVAR ° d ONLN d 9 Å ú ç +mySpBlk: SpBlock; ° d ONLN d O è ú õ ¿ *myErr: ° d ONLN d X è “ õ ˆ )6OSErr; ° d ONLN d ` ´ ä ∑ ® ( ¥ äBEGIN ° d ONLN d j π ú ≈í +){Set required values in parameter block.} ° d ONLN d ò « ú ” ¸ *WITH mySpBlk DO ° d ONLN d ≠ ’ ú · ∫ *BEGIN ° d ONLN d ∏ „ Æ Ô +spParamData := 1; ° d ONLN d – „, Ôb )~ {disable} ° d ONLN d fl Ò Æ ˝ ( ˙ ÆspSlot := $0A; ° d ONLN d Ù Ò, ˝z )~
{slot number} ° d ONLN d ˇ Æ ˆ ( Æ spID := 128; ° d ONLN d ˇ, Ä )~{sResource ID} ° d ONLN d.
Æ ( ÆspExtDev := 0; ° d ONLN dC
,∂ )~{ID of external device} ° d ONLN d_ ú' ¥ ($ úEND; ° d ONLN dh) ú5b *!myErr := SetSRsrcState(@mySpBlk); ° d ONLN dé7 úCÄ *&IF myErr <> noErr THEN DoError(myErr); ° d ONLN d∫S ú_ ¸ * WITH mySpBlk DO ° d ONLN dœa úm ∫ *BEGIN ° d ONLN d⁄o Æ{ +spParamData := 0; ° d ONLN dÚo,{\ )~{enable} ° d ONLN d } Æâ (Ü ÆspSlot := $0A; ° d ONLN d},âz )~
{slot number} ° d ONLN d(ã Æó ˆ (î Æ spID := 131; ° d ONLN d;ã,óÄ )~{sResource ID} ° d ONLN dOô Æ• (¢ ÆspExtDev := 0; ° d ONLN ddô,•∂ )~{ID of external device} ° d ONLN dÄß ú≥ ¥ (∞ úEND; ° d ONLN dâµ ú¡b *!myErr := SetSRsrcState(@mySpBlk); ° d ONLN dØ√ úœÄ *&IF myErr <> noErr THEN DoError(myErr); ° d ONLN d÷— ä› ¢ (⁄ äEND;
H 4 H
ä
ˇ·ˇ‚7^
ˇˇ◊ . ˇ◊ ° d ONLN d€Û ä ß *&Sear ı@ ° d ONLN dflÛ ß ) ching for sResour <P ° d ONLN dÛ!k )z ce Data Str ® ° d ONLN d˚Ûkê )Juctur ÇP ° d ONLN d Ûêû )%es ˇˇˇˇˇˇ ® )~3
° d ONLN d
ä ‰ ( äThe Slot Manager pr Ù‡ ° d ONLN d
‰) )Zovides several r 1‡ ° d ONLN d&
*r )Foutines that sear ” ° d ONLN d7
r± )Hch for sResour ‡ ° d ONLN dE
≤fl )@ ce data str ˘‡ ° d ONLN dP
fiı ),uctur ¿ ° d ONLN dU
ˆ )es in ° d ONLN d[ ä" Ã ( äthe Slot Resour 3† ° d ONLN dj Õ" fi )Cce T #@ ° d ONLN dn fi" )
able. These r d@ ° d ONLN d{"Ò )72outines all allow you to specify for which sResour õ@ ° d ONLN d≠Ò" )‹ce data ° d ONLN dµ" ä. ï (+ ästr fi ° d ONLN d∏" ï. ¨ ) uctur c‡ ° d ONLN dΩ" ≠. ’ )
es to sear Ó ° d ONLN d«" ’.+ )(ch, but they each pr ø† ° d ONLN d€",.w )Wovide slightly dif ˚† ° d ONLN dÌ"w.É )Kfer fi ° d ONLN d"É.∑ ) ent options. . ° d ONLN d˝4 ä@ û (= äThe ° d ONLN d4 û@ Ï )
SFindSRsrcPtr ° d ONLN d4 Ï@ )N and ° d ONLN d4@I ) SGetSRsrcPtr ° d ONLN d 4I@ )H
functions ar R` ° d ONLN d,4@ÿ )6e the simplest. The ° d ONLN d@@ äL ÿ (I ä
SFindSRsrcPtr ° d ONLN dM@ ÿL )N function r R` ° d ONLN dX@L ),equir $¿ ° d ONLN d]@L ).es you to specify a slot number and an sResour ˜ ° d ONLN dã@‰L˝ )…ce ID . ° d ONLN dëL äX ° (U äand r ≤ ° d ONLN dñL °X( ) eturns a pointer to the sResour >¿ ° d ONLN dµL)XV )à ce data str 4¿ ° d ONLN d¿LVXm )-uctur ∫† ° d ONLN d≈LmX∑ )e with the specifi ¢‡ ° d ONLN d◊L∏XÓ )K
ed ID in the ° d ONLN d‰X äd ¶ (a äspecifi Ó ° d ONLN dÎX ¶d » ) ed slot. . ° d ONLN dıj äv û (s äThe ° d ONLN d˘j ûv Ê ) SGetSRsrcPtr ° d ONLN dj Êv¯ )H? function allows you to specify that you want the function to r R` ° d ONLN dDj¯v (s¯eturn . ° d ONLN dJv äÇ ( ä a pointer to the next sResour ˛Ä ° d ONLN dgvÇ5 )~ ce data str ÙÄ ° d ONLN drv5ÇL )-uctur z` ° d ONLN dwvMÇ˙ )(e—that is, the one with the next higher ˇˇ˚ä . ° d ONLN düÇ äé ¨ (ã äsResour R` ° d ONLN d¶Ç ¨é ¯ )"ce ID. When sear ^ ° d ONLN d∂Ç ˘ék )Mching for the next sResour ◊Ê ° d ONLN d–Çkéô )r ce data str ∫˙ ° d ONLN d€Çöé∞ )/uctur çZ ° d ONLN d‡Ç∞éÀ )e, the ˇˇÚû Ñn ° d ONLN dÁÇÃé ) SGetSRsrcPtr ˇˇ˚ä Ñn ° d ONLN dÛÇé )H . ° d ONLN dÙé äö (ó ä function also allows you to sear † ° d ONLN déöà )å(ch for both enabled and disabled sResour »` ° d ONLN d<éÃöÌ )∂ce data ° d ONLN dDö ä¶ ï (£ ästr fi ° d ONLN dGö ï¶ ¨ ) uctur c‡ ° d ONLN dLö ≠¶ )es, or enabled ones only 3 ° d ONLN ddö¶ )i. ˇ @ ˇ ˇˇˇˇ @
SNextSRsrc ° d ONLN d \ º h — )< and ° d ONLN d \ — h ) SGetSRsrc ° d ONLN d \ h= )6
functions ar R` ° d ONLN d ) \= hf )6 e similar ï ° d ONLN d 2 \e h≥ )(, although they r g` ° d ONLN d C \≥ h› )N eturn mor 9¿ ° d ONLN d L \› h‰ )*e . ° d ONLN d N h l t Ú ( q l information about the sResour † ° d ONLN d k h Û t )á ce data str † ° d ONLN d v h t7 )-uctur éÄ ° d ONLN d { h7 ty )e, such as the fi Ö ° d ONLN d å hz tπ )Celds of its sRsr -‡ ° d ONLN d ú h∫ tƒ )@cT ÿ‡ ° d ONLN d û h√ tÌ ) ype entry ˜ ° d ONLN d ß hÏ tÒ )). . ° d ONLN d ™ z l Ü Ä ( É lThe ° d ONLN d Æ z Ä Ü ‘ )SNextTypeSRsrc ° d ONLN d º z ‘ Ü È )T and ° d ONLN d ¡ z È Ü7 )
SGetTypeSRsrc ° d ONLN d Œ z7 Ü® )N functions allow even mor R` ° d ONLN d Á z® Ü≈ )qe contr $¿ ° d ONLN d Ó z≈ Üfi ) ol. W ò ° d ONLN d Û z› ÜÓ )ith . ° d ONLN d ˜ Ü l í Í ( è l these functions, you can sear H@ ° d ONLN d Ü Î íP )ch for the next sResour \Ä ° d ONLN d+ ÜP í} )e ce data str RÄ ° d ONLN d6 Ü} íî )-uctur ÿ` ° d ONLN d; Üî íÁ )e with a particular ° d ONLN dO í l û è ( õ lsResour ≥@ ° d ONLN dV í è û ∞ )#ce type. ° d ONLN d_ § l ∞ r ( ≠ lT µ¿ ° d ONLN d` § q ∞- ))able 1-1 summarizes the Slot Manager sear , ° d ONLN dâ §. ∞> )Ωch r ≤† ° d ONLN dç §> ∞· )&outines and the options available for ° d ONLN d≥ ∞ l º Ç ( π leach.
fl * Á¯ 4 ‡ * Á¯ „ * „˛
ˇ·ˇ‚7^
° d ONLN dˇˇ *$ Table 3-3 ° d ONLN dπ ’ ™ ‡" )> Slot Manager search routines ° d ONLN dÿ Ì ã ¯ † ( ı ãState ¿ ° d ONLN d› Ì ° ¯ £ ) ˇ‡ ° d ONLN dfi Ì £ ¯ ≠ )of ° d ONLN d„ ÌW ¯t )¥Which ° d ONLN dÍ ÌØ ¯¥ )XT T ° d ONLN dΠ̥ ¯√ )ype ’ ° d ONLN dÓ Ì√ ¯≈ ) V ° d ONLN dÔ ÌΔ ¯– )of ° d ONLN dÙ ˜ ã æ ( ˇ ã
sResources É ° d ONLN d˛ ˜ æ ¿ )3 ° d ONLN dˇ ˜ ¡ » )it ° d ONLN d ˜ )/Slots ¿ ° d ONLN d ˜ ) ˇ‡ ° d ONLN d ˜ )it ° d ONLN d
˜WÖ )O sResource Ç0 ° d ONLN d ˜Öá ). P ° d ONLN d ˜àè )it ° d ONLN d ˜Ø› )' sResource Ç0 ° d ONLN d$ ˜›fl ). P ° d ONLN d% ˜‡Á )it ° d ONLN d) * O ( *Function ° d ONLN d2 ã ≤ )asearches ÑP ° d ONLN d: ≤ ¥ )' p ° d ONLN d; µ ¿ )for ° d ONLN d? );searches ° d ONLN dHW ~ )gsearches ÑP ° d ONLN dP~ Ä )' p ° d ONLN dQÅ å )for ° d ONLN dUØ ÷ ).searches ÑP ° d ONLN d]÷ ÿ )' p ° d ONLN d^Ÿ ‰ )for
. ° d ONLN db * x ( *
SFindSRsrcPtr . ° d ONLN dp ã ≈ )a Enabled only ° d ONLN d}
)eSpecifi ‡ ° d ONLN dÑ
, ) ed slot ° d ONLN dçWt )JSpecifi ‡ ° d ONLN dîtÅ ) ed ° d ONLN dòØÿ );Any type ° d ONLN d£ & Ú (# ° d ONLN d•W&z )gsResour ≥@ ° d ONLN d¨z&õ )#ce only . ° d ONLN dµ, *8 f (5 *
SNextSRsrc . ° d ONLN d¿, ã8 ≈ )a Enabled only ° d ONLN dÕ, 8
)eSpecifi ‡ ° d ONLN d‘,
8= ) ed slot and ° d ONLN d‡,W8í )J Next sResour ∂¿ ° d ONLN dÏ,í8ù );ce ° d ONLN d,Ø8ÿ ) Any type ° d ONLN d˚7 C% (@
higher slots ° d ONLN d 7WCm )gonly . ° d ONLN dI *U r (R * SGetSRsrcPtr ° d ONLN dI rU z )H*, . ° d ONLN d I ãU ë )Y @Ä ° d ONLN d I ëU )
our choice of ° d ONLN d-I U ˆ )_Y @Ä ° d ONLN d.I ˆUA )our choice of one ° d ONLN d@IWU] )aY @Ä ° d ONLN dAI]Uò )our choice of ° d ONLN dPIØUÿ )RAny type . ° d ONLN dYT *` ` (] * SGetSRsrc ° d ONLN dbT `` e )6* . ° d ONLN ddT ã` – )+enabled only or ° d ONLN dtT `" )e slot only or ° d ONLN dÅTW`s )gspecifi Ó ° d ONLN dàTs`Ä ) ed ° d ONLN dç_ ãk ◊ (h ãboth enabled and ° d ONLN dû_ k )especifi Ó ° d ONLN d•_ k< ) ed slot and ° d ONLN d±_Wkz )KsResour ≥@ ° d ONLN d∏_zkë )#ce or ° d ONLN d¿j ãv ∞ (s ãdisabled ° d ONLN d…j v# )e higher slots ° d ONLN d÷jWvè )g next sResour 9@ ° d ONLN d‚jêvô )9ce . ° d ONLN dÂ| *à ~ (Ö *SNextTypeSRsrc . ° d ONLN dÙ| ãà ≈ )a Enabled only ° d ONLN d| à
)eSpecifi ‡ ° d ONLN d|
à= ) ed slot and ° d ONLN d|Wàí )J Next sResour ∂¿ ° d ONLN d |íàõ );ce ° d ONLN d#|Øàà ) Specifi ‡ ° d ONLN d*|ÃàÔ ) ed type ° d ONLN d5á ì% (ê
higher slots ° d ONLN dCáWìj )gonly ° d ONLN dHáØì¬ )Xonly . ° d ONLN dMô *• x (¢ *
SGetTypeSRsrc ° d ONLN dZô x• } )N* . ° d ONLN d\ô ã• ë )Y @Ä ° d ONLN d]ô ë• )
our choice of ° d ONLN dkô • ˆ )_Y @Ä ° d ONLN dlô ˆ•/ )
° d ONLN d ” l‹ q (⁄ l* QÄ ° d ONLN d” q‹ w )A ŒÄ ° d ONLN d” v‹ Ì )!vailable only with system softwar ° d ONLN d$” Ó‹K )xe version 7.0 Slot Manager
° d ONLN d?ˆ l ö (ˇ l Listing 3-2 @ ° d ONLN dJˆ õ Ô )/ shows how to sear YÄ ° d ONLN d\ˆ Ô… )T2ch all slots for both enabled and disabled sResour ˙@ ° d ONLN déˆ…Í )⁄ce data . ° d ONLN dñ l x ( lstr l ° d ONLN dô x é ) uctur >` ° d ONLN dû é · )es with an sResour ¿ ° d ONLN d∞ ·7 )Sce type category of ¿ ° d ONLN dƒ7s )V
catDisplay ¿ ° d ONLN dŒs∑ )< and an sResour „ ° d ONLN d›∂ÿ )Cce type ° d ONLN d l Æ ( lsubcategory of ° d ONLN dÙ Æ fi )BtypVideo ° d ONLN d¸ fi · )0. ˇt @ ˇ ˇˇˇˇ @
° d ONLN dˇˇ ( d ä Listing 3-2 ° d ONLN d \ Œ go )D'Searching for sResource data structures ,
Courier
. ° d ONLN d ( s H Z ( | HVAR ° d ONLN d . Å f ç à + mySpBlk: SpBlock; ° d ONLN d B è f õ ä *myErr: ° d ONLN d K è ú õ ¿ )6OSErr; ° d ONLN d S ´ H ∑ f ( ¥ HBEGIN ° d ONLN d [ π f ≈\ + ){Set required values in parameter block.} ° d ONLN d á « f ” Δ *WITH mySpBlk DO ° d ONLN d ö ’ f · Ñ *BEGIN ° d ONLN d £ „ x Ô fi +spParamData := 1; ° d ONLN d Ω „ ÔÚ )¢${fAll flag 1: search all sResources} ° d ONLN d Ó Ò ˝Ï *#{fOneSlot flag 0: search all slots} ° d ONLN d ˇ x ( xspCategory := $catDisplay; ° d ONLN d8 ˇ ⁄ )¢ {search for Category catDisplay} ° d ONLN d\
x ( xspCategory := $typeVideo; ° d ONLN d~
¬ )¢ {search for cType typeVideo} ° d ONLN dû x' à ($ xspDrvrSW := 0; ° d ONLN dµ'Œ )¢ {this field not being matched} ° d ONLN d◊) x5 à (2 xspDrvrHW := 0; ° d ONLN dÓ)5Œ )¢ {this field not being matched} ° d ONLN d7 xC à (@ xspTBMask := 0; ° d ONLN d'7C˛ )¢&{match only Category and cType fields} ° d ONLN dQE xQ ¿ (N x spSlot := 0; ° d ONLN dfEQ™ )¢{start search from here} ° d ONLN dÇS x_ ¥ (\ x
spID := 0; ° d ONLN dïS_™ )¢{start search from here} ° d ONLN d±a xm à (j xspExtDev := 0; ° d ONLN d»amº )¢{ID of the external device} ° d ONLN dÊo f{ ~ (x fEND; ° d ONLN dÌ} fâ ® * myErr := 0; ° d ONLN d¸ô f• Í * WHILE myErr = noErr DO ° d ONLN d ô•º )¥{loop to search sResources} ° d ONLN d:ß f≥ Ñ (∞ fBEGIN ° d ONLN dCµ x¡> +!myErr := SGetTypeSRsrc(@mySpBlk); ° d ONLN dh√ xœ *MySRsrcProcessor(mySpBlk); ° d ONLN dã√œ‡ )¢!{your routine to process results} ° d ONLN dØ— f› ~ (⁄ fEND; ° d ONLN d∂fl fÎÄ */IF myErr <> smNoMoresRsrcs THEN DoError(myErr); ° d ONLN dÊÌ H˘ ` (ˆ HEND;
7 H= 47 H< 7 ä7
ˇ·ˇ‚7^
ˇˇ◊ . ˇ◊ ° d ONLN dÎ% ä6$ +B<Getting Information fr ®` ° d ONLN d%$6u )ö
om sResour @ ° d ONLN d %v6¿ )R ce Data Str ´∞ ° d ONLN d%¿6 )Juctur Ü ° d ONLN d%Â6Û )%es ˇˇˇˇˇˇ ® ))3
° d ONLN d < äH Ø (E ä If you ar ° d ONLN d'< ∞H# )& e writing a driver for a car ‘Ä ° d ONLN dC<#H˘ )s2d device, you will most likely want access to the ° d ONLN duH äT ˝ (Q äinformation in an sResour y¿ ° d ONLN déH ˝T* )s ce data str o¿ ° d ONLN dôH*TA )-uctur ı† ° d ONLN dûHATJ )e. ° d ONLN d¢Z äf ‰ (c äThe Slot Manager pr Ù‡ ° d ONLN dµZ ‰fb )Z ovides many functions that r ∂@ ° d ONLN d—Zcfª )eturn information fr a† ° d ONLN dÂZºf )Yom the entries of an . ° d ONLN d˙f är ¨ (o äsResour R` ° d ONLN df ¨r € )" ce data str >` ° d ONLN d f €r Ò )/uctur ¿ ° d ONLN df Òr )e. The ¿ ° d ONLN dfrQ ) SOffsetData ¿ ° d ONLN d#fQrV )B, ¿ ° d ONLN d%fVrå ) SReadByte ¿ ° d ONLN d.får§ )6, and ¿ ° d ONLN d4f§r⁄ ) SReadWord ¿ ° d ONLN d=f⁄r )6 functions ° d ONLN dHr ä~ é ({ är R` ° d ONLN dIr é~ Á )eturn information fr $¿ ° d ONLN d]r Á~ )Y om the of ˜ ° d ONLN dfr~* ))fset fi ˜ ° d ONLN dmr*~u )eld of an sResour …Ä ° d ONLN d~ru~™ )K
d data str ¿ ° d ONLN dÁ~Ìä ),uctur „ ° d ONLN dÏ~ä
)es ° d ONLN dÔä äñ ‚ (ì äpointed to by the of R` ° d ONLN dä ‚ñ ¸ )Xfset fi R` ° d ONLN d
ä ¸ñG )eld of an sResour $¿ ° d ONLN däGñ| )K
ce list entry ° d ONLN d(ä{ñî )4. The ° d ONLN d.äîñ÷ ) SFindStruct ° d ONLN d9ä÷ñÎ )B and ° d ONLN d>ñ ä¢ Ã (ü ä SReadStruct ° d ONLN dIñ â| )B) functions allow access to other data str l ° d ONLN drñ|¢í )∞uctur >` ° d ONLN dwñí¢¸ )es pointed to by sResour ¿ ° d ONLN dèñ¸¢ )jce . ° d ONLN dí¢ äÆ ∫ (´ ä
° d ONLN d \ l h ö ( e l Listing 3-3 @ ° d ONLN d \ õ h )/ shows an example of r í@ ° d ONLN d ! \ h_ )eeading information fr î¿ ° d ONLN d 6 \_ h† )_
om an sResour ‚‡ ° d ONLN d C \† hÎ )Ace. This example ° d ONLN d T h l t Ï ( q l examines the name of the car Ø ° d ONLN d p h Ï t& )Äd in slot $0A.
ñ * ö¯ 4 ó * ô¯ " ó *a
ˇ·ˇ‚7^
° d ONLN dˇˇ ( î l Listing 3-3 ° d ONLN d å ∞ óQ )D'Searching for sResource data structures ,
Courier
. ° d ONLN d ß £ l Ø ~ ( ¨ lVAR ° d ONLN d Ø ± ~ Ω ‰ +mySpBlk: SpBlock; ° d ONLN d ≈ ø ~ À ¢ *myErr: ° d ONLN d Œ ø ¥ À ÿ )6OSErr; ° d ONLN d ÷ € l Á ä ( ‰ lBEGIN ° d ONLN d ‡ È ~ ı⁄ +:{First get a pointer to the Board sResource for slot $0A.} ° d ONLN d ˜ ~ fi *WITH mySpBlk DO ° d ONLN d4 ~ ú *BEGIN ° d ONLN d? ê ‰ +spSlot := $0A; ° d ONLN dU û )ê{search in this slot} ° d ONLN dp! ê- à (* ê
spID := 1; ° d ONLN dÇ! -Ê )ê!{assume Board sResource has ID 1} ° d ONLN d®/ ~; ñ (8 ~END; ° d ONLN d±= ~ID *!myErr := SFindSRsrcPtr(@mySpBlk); ° d ONLN d◊K ~Wb *&IF myErr <> noErr THEN DoError(myErr); ° d ONLN dg ~s‡ * ;{The spsPointer field of mySpBlock now contains a pointer } ° d ONLN dCu ~Å‘ *9{ to the Board sResource list. The SGetCString function } ° d ONLN dÅÉ ~èí *.{ uses this field as one of two input fields.} ° d ONLN d¥ë ~ù Í *mySpBlk.spID := 2; ° d ONLN dœë ùÜ )¢{sRsrcName entry} ° d ONLN dÊ≠ ~π8 (∂ ~ myErr := SGetCString(@mySpBlk); ° d ONLN d
ª ~«b *&IF myErr <> noErr THEN DoError(myErr); ° d ONLN d6◊ ~„Œ * 8{The spResult field now points to a copy of the cString} ° d ONLN ds ~ÒV *$MyProcessCardName(mySpBlk.spResult); ° d ONLN dòÛ lˇ Ñ (¸ lEND;
*(¯ 4
*'¯
9 *A¯ 49 *@¯ 9 *9˛
ˇ·ˇ‚7^
ˇˇ£‰ . ˇÆ ° d ONLN dù% *7 (3 * Reference to the Slot Manager ˇˇˇˇˇˇ ⁄| (3Ó3
an sResour † ° d ONLN dv` ùl )1 ce data str ˙† ° d ONLN dÅ` …l ‡ ),uctur ÄÄ ° d ONLN dÜ` ·là )&e given some information about it or r ,‡ ° d ONLN d¨`âlŸ )®ead information fr ÊÄ ° d ONLN dæ`Ÿl˜ )Pom an ° d ONLN dƒl lx ¡ (u lentry in an sResour Ä ° d ONLN d◊l ¬x )Vce list. Some of the r f ° d ONLN dÌlxz )Xoutines allow you to r ` ° d ONLN dl{xÊ )aead and set information ° d ONLN dx lÑ ƒ (Å labout expansion car -‡ ° d ONLN d.x ≈Ñ )Y@ds, such as their parameter RAM values, and others allow you to ° d ONLN dnÑ lê ˇ (ç l manipulate Slot Manager data str 9Ä ° d ONLN déÑ ê )îuctur ø` ° d ONLN dìÑêz )es, like the Slot Resour # ° d ONLN d´Ñ{êå )dce T ¿ ° d ONLN dØÑåê† )able. ˇ @ ˇ ˇˇˇˇ @
ˇ·ˇ‚7^
4 H \ , Palatino
. +ä"CHAPTER €` )\3 , Helvetica
( @ äThe Slot Manager 4⁄ ä˙ (‡ ä Reference to the Slot Manager
ˇˇ◊ ˇ◊ ° d ONLN d \ H m Ä ( i HData Str ¢Ä ° d ONLN d \ Ä m • )8uctur |– ° d ONLN d
\ • m ≥ )%es ˇˇˇˇˇˇ ® ( i3
° d ONLN d y ä Ö ( Ç ä Every Slot Manager function r “† ° d ONLN d - y Ö& )Öequir ȇ ° d ONLN d 2 y& Ö˘ )0es a pointer to a parameter block as a parameter fi‡ ° d ONLN d b y˘ Ö )”, and . ° d ONLN d h Ö ä ë é ( é är R` ° d ONLN d i Ö é ë ∏ )
. ° d ONLN dX ÿ ä ‰, ( · äTYPE SpBlockPtr = ^SpBlock; ° d ONLN dt Ê ä Ú *SpBlock = PACKED RECORD ° d ONLN dê Ù ú “ + spResult: ° d ONLN dû Ù ˆ & )ZLongInt; ° d ONLN d™ Ù> t )H {result} ° d ONLN d∏ ú fi ( ú spsPointer: ° d ONLN d» ˆ )ZPtr; ° d ONLN d–>∂ )H {structure pointer} ° d ONLN dÈ ú Δ ( úspSize: ° d ONLN dı ˆ & )ZLongInt; ° d ONLN d> ∂ )H {size of structure} ° d ONLN d ú* Í (' ú
spOffsetData: ° d ONLN d, ˆ*& )ZLongInt; ° d ONLN d8 >*§ )H {offset or data} ° d ONLN dN, ú8 Í (5 ú
spIOFileName: ° d ONLN d`, ˆ8 )ZPtr; ° d ONLN dh,>8Ê )H {reserved for Slot Manager} ° d ONLN dâ: úF ‰ (C ú spsExecPBlk: ° d ONLN dö: ˆF& )ZLongInt; ° d ONLN d¶:>F )H$ {pointer to SEBlock data structure} ° d ONLN dœH úT ‰ (Q ú spParamData: ° d ONLN d‡H ˆT )ZPtr; ° d ONLN dËH>Tn )H {flags} ° d ONLN dıV úb Δ (_ úspMisc: ° d ONLN dV ˆb& )ZLongInt; ° d ONLN d
V>bÊ )H {reserved for Slot Manager} ° d ONLN d.d úp fi (m ú spReserved: ° d ONLN d>d ˆp& )ZLongInt; ° d ONLN dJd>pÊ )H {reserved for Slot Manager} ° d ONLN dkr ú~ Í ({ ú
spIOReserved: ° d ONLN d}r ˆ~& )ZINTEGER; ° d ONLN dâr>~Ê )H {ioReserved field from SRT} ° d ONLN d™Ä úå “ (â ú spRefNum: ° d ONLN d∏Ä ˆå& )ZINTEGER; ° d ONLN dƒÄ>å⁄ )H {driver reference number} ° d ONLN d„é úö fi (ó ú spCategory: ° d ONLN dÛé ˆö& )ZINTEGER; ° d ONLN dˇé>ö )H# {Category field of sResource type} ° d ONLN d'ú ú® à (• úspCType: ° d ONLN d4ú ˆ®& )ZINTEGER; ° d ONLN d@ú>®˛ )H {cType field of sResource type} ° d ONLN de™ ú∂ “ (≥ ú spDrvrSW: ° d ONLN ds™ ˆ∂& )ZINTEGER; ° d ONLN d™>∂ )H! {DrvrSW field of sResource type} ° d ONLN d•∏ úƒ “ (¡ ú spDrvrHW: ° d ONLN d≥∏ ˆƒ& )ZINTEGER; ° d ONLN dø∏>ƒ )H! {DrvrHW field of sResource type} ° d ONLN dÂΔ ú“ “ (œ ú spTBMask: ° d ONLN dÛΔ ˆ“8 )Z SignedByte; ° d ONLN dΔ>“⁄ )H {sResource type bit mask} ° d ONLN d!‘ ú‡ Δ (› úspSlot: ° d ONLN d-‘ ˆ‡8 )Z SignedByte; ° d ONLN d<‘>‡í )H {slot number} ° d ONLN dO‚ úÓ ∫ (Î úspID: ° d ONLN dY‚ ˆÓ8 )Z SignedByte; ° d ONLN dh‚>Óò )H {sResource ID} ° d ONLN d| ú¸ “ (˘ ú spExtDev: ° d ONLN dä ˆ¸8 )Z SignedByte; ° d ONLN dô>¸º )H {external device ID} ° d ONLN d≥˛ ú
à ( úspHwDev: ° d ONLN d¿˛ ˆ
8 )Z SignedByte; ° d ONLN dœ˛>
º )H {hardware device ID} ° d ONLN dÈ ú ‰ ( ú spByteLanes: ° d ONLN d˙ ˆ8 )Z SignedByte; ° d ONLN d >∞ )H {valid byte lanes} ° d ONLN d! ú& Ã (# úspFlags: ° d ONLN d. ˆ&8 )Z SignedByte; ° d ONLN d=>&Ï )H {flags used by Slot Manager} ° d ONLN d_( ú4 ¿ (1 úspKey: ° d ONLN dj( ˆ48 )Z SignedByte; ° d ONLN dy(>4Ê )H {reserved for Slot Manager} ° d ONLN dñ6 äB ¢ (? äEND;
R Ha 4R Ha
. ° d ONLN dˇˇ *Field descriptions
ˇ·ˇ‚7^
. ° d ONLN dõ_ äk ∫ *spResult . ° d ONLN d§_ Êk Ì )\A ∫† ° d ONLN d•_ Ìk@ ) general-purpose fi d ° d ONLN d∏_Ak´ )Teld used to contain the r ˇ ° d ONLN d—_´k )jesults r £` ° d ONLN dŸ_Àk˝ ) eturned by ° d ONLN d‰k Êw (t Ê several dif {‡ ° d ONLN dÔkw ).fer ^` ° d ONLN dÚk w4 ) ent r Ä¿ ° d ONLN d˜k4wV )outines. . ° d ONLN d z äÜ Δ (É ä
spsPointer . ° d ONLN d z ÊÜ Ì )\A ∫† ° d ONLN d z ÌÜF ) pointer to a data str fi† ° d ONLN d"zFÜ] )Yuctur dÄ ° d ONLN d'z^ÜÅ )e. The fi v† ° d ONLN d0zÅܯ )#eld can point to an sResour 6@ ° d ONLN dKz˘Ü )xce ° d ONLN dNÜ Êí (è Êdata str º ° d ONLN dVÜí )!uctur B ° d ONLN d[Ü í )4e, a data block, or a declaration ROM, depending on ° d ONLN dèí Êû ˙ (õ Êthe r ¢` ° d ONLN dîí ˙û] )outine being executed. . ° d ONLN d´° ä≠ Æ (™ äspSize . ° d ONLN d≤° Ê≠X )\The size of the data block. ˇ ê @ ˇ ˇˇˇˇ @
ch to sResour ’¿ ° d ONLN d1 ≈% —R ); ce data str À¿ ° d ONLN d< ≈R —i )-uctur Q† ° d ONLN dA ≈j —¥ )es on a single car @ ° d ONLN dS ≈µ —Í )Kd. Bit 2 (the . ° d ONLN da — » › Ê ( ⁄ »fNext ° d ONLN df — Ê › Ï ) f PÄ ° d ONLN dh — Ï ›Ñ )"lag) indicates when set that the r "‡ ° d ONLN dä —Ñ ›¶ )òoutine f Û` ° d ONLN dí —• ›› )!
»if 1, it is disabled). . ° d ONLN dä l ê ( lspMisc . ° d ONLN dë » m )\$Reserved for use by the Slot Manager Ô ° d ONLN dµl n )§. . ° d ONLN d∑" l. ® (+ l
spReserved . ° d ONLN d¬" ». )\Reserved for futur ¢ ° d ONLN d‘".1 )Qe use. . ° d ONLN d€1 l= ¥ (: l spIOReserved ° d ONLN dË1 »= )\The value of the ° d ONLN d˘1=Q )M
ioReserved ° d ONLN d1Q=Z )< fi ° d ONLN d1Z=s ) eld fr R` ° d ONLN d 1s=∂ )om the sResour $¿ ° d ONLN d1∂=Ÿ )Cce data . ° d ONLN d"= »I ” (F »str fi ° d ONLN d%= ”I Í ) uctur c‡ ° d ONLN d*= ÎIa ) e’s entry in the Slot Resour ~@ ° d ONLN dF=aIr )vce T m‡ ° d ONLN dJ=rIÜ )able. . ° d ONLN dPL lX ú (U lspRefNum . ° d ONLN dYL »X ˝ )\ The driver r Z ° d ONLN deL ˝X
e, if ther W` ° d ONLN d∑XTdw )$ e is one. . ° d ONLN d¡g ls ® (p l
spCategory . ° d ONLN dÃg »s )\The Category fi Ò‡ ° d ONLN d€g s[ )Deld of the sResour † ° d ONLN dÌg\s} )Pce type. . ° d ONLN dˆv lÇ ñ ( lspCType . ° d ONLN d˛v »Ç  )\The cT f¿ ° d ONLN dv ÂÇ ˝ ) ype fi N` ° d ONLN d
v ˛ÇM )eld of the sResour v ° d ONLN d vMÇn )Oce type. . ° d ONLN d%Ö lë ú (é lspDrvrSW . ° d ONLN d.Ö »ëA )\The DrvrSW of the sResour û@ ° d ONLN dGÖAëb )yce type. . ° d ONLN dPî l† ú (ù lspDrvrHW . ° d ONLN dYî »†D )\The DrvrHW of the sResour ؇ ° d ONLN drîD†e )|ce type. . ° d ONLN d{£ lØ ú (¨ lspTBMask . ° d ONLN dÑ£ »Ø œ )\A ∫† ° d ONLN dÖ£ œØd ) mask that determines which sRsr ˆ ° d ONLN d•£dØn )ïcT ì† ° d ONLN dߣnØÜ )
ype fi {@ ° d ONLN d≠£áØÈ )elds the Slot Manager ° d ONLN d√Ø »ª! (∏ »examines when sear ï† ° d ONLN d’Ø!ªn )Yching for sResour ` ° d ONLN dÊØoªú )N ce data str ` ° d ONLN dÒØúª≥ )-uctur ã@ ° d ONLN dˆØ≥ªæ )es. . ° d ONLN d˙æ l ê (« lspSlot . ° d ONLN dæ » Ñ )\)The number of the slot with the NuBus car À¿ ° d ONLN d*æÑ Œ )ºd containing the ° d ONLN d; »÷ À (” »r E ° d ONLN d< Ã÷ )equested, or r ä` ° d ONLN dJ ÷S )<eturned, sResour z ° d ONLN dZ S÷Ä )K ce data str p ° d ONLN de Ä÷ó )-uctur ˆ ° d ONLN dj ó÷û )e. . ° d ONLN dmŸ lÂ Ñ (‚ lspID . ° d ONLN drŸ »Â ˛ )\ The sResour Ô ° d ONLN d}Ÿ ˛Â6 )6ce ID of the r ∞` ° d
